A simple assignment to self of a DOM object’s location.host property, within a simple client side embedded JavaScript, as shown below, could result in get requests inundation:
                                     <script> location.host=location.host </script>
Above could be fed as input to a simple web form (devoid of input validation checks) to demonstrate the problem.  Admittedly, the problem could be alleviated with the client’s rate limiting feature.  However, should this assignment be allowed?  Wouldn’t it be reasonable to expect the JavaScript engine to nop this assignment?  While the problem itself looks trivial on the surface, it could be creatively used.  For example, search results tend to reflect back the input.  What if a frivolous implementation did not properly vet the input?  It could result in momentarily DDoS attacks.

I stumbled on this issue several months back and tried to raise it at a different scope.  Thought I would publish it here now, along with a demo.  Comments welcome!

I recently stumbled on a potential issue in PHP's pcntl module.  I tried getting the attention of the PHP development community via php-bugs@lists.php.net and more, to confirm one way or other.  PHP bugs general mailing list bounced back.  And, I haven't had much luck yet, getting the attention of the right folks in the PHP/pcntl development team, via other means as well.  So, I figured I would publish here, what may be a potential issue.

While using PHP's pcntl module and it's alarm feature, it is able to interrupt sleep, whereas, it is unable to do the same for netcat listen.  This issue is further demonstrated using the code below (borrowed from here, and modified for our test).  It would help to known whether this is a bug or an overlooked user error.

<?php

/**
* Because we shouldn't handle asynchronous
* events in synchronous manner.
*/
pcntl_async_signals(TRUE);

/**
* Some flag we can change to know for sure
* that our operation timed out.
*/
$timed_out = FALSE;

/**
* Register SIGALRM signal handler to avoid
* getting our process killed when signal arrives.
*/
pcntl_signal(SIGALRM, function($signal) use ($timed_out) {
  $timed_out = TRUE;
});

/**
* Now we set our timeout for 2 seconds, but it's not set in stone
* we can call pcntl_alarm() anytime to extend or to turn if off.
*/
pcntl_alarm(2);

/* Sleep will snap out in 2 sec while nc won't follow suit.
 * Can be tested by commenting one or the other as well.
 */
sleep(2000);
echo `nc -nlvp 8000`;

/**
* If our blocking operation didn't timed out then
* timer is still ticking, we should turn it off ASAP.
*/
$timed_out || pcntl_alarm(0);

/**
* And now we do whatever we want to do.
 */
echo "Operation aborted\n";
?>

Device search engines are useful to take an inventory of the internet facing devices.  Blue team security engineers use it towards better securing the perimeter under their study, where as red team security engineers leverage it to find inroads into a facility they attempt to compromise.  It is useful for organizations to keep a tab on it's own outward facing devices, off chance a device should get exposed unintentionally.  Systemic arms guarding the cyber infrastructures ought to be using it heavily and it would be a bit surprising if they don't have a proprietary mechanism to keep tabs on perimeters of interest to them.  There are very many other uses as well for device search engines.  More important than all the above, bad actors are always scouting for entry points into organizations and they heavily rely on device search engines.  This makes the device search engines a two edged sword, and it is only natural that those providing the service would want to guard it.

A list of currently available device search engines are here.  Within that list, I have used Shodan and Censys.  I have found the both of them to be useful and their response time to queries excellent, thus far.  They both require you to create an account with them and expect you to be logged in, beyond a couple of simple queries.  That is understandable, especially given the risk involved in allowing the results to be freely available.  However, I did notice that the results between the engines I have used are at times widely different.  While some of the differences could be explained away given the differences in algorithms, caching/purging of stale data etc., I am not entirely convinced that device search engines can escape standardization any further, if they want to guarantee the integrity and comprehensiveness of their results, that is, as well as they can be guaranteed, with its own caveats, which ought to be equivalent to that of their competitors.  Technology sector is better served if multiple geographies provide search engine service (as opposed to search engine providers concentrated in one or few geographies and renting servers in varied geographies).  We would also be better served with services that reconcile the results from varied providers, to help us better understand the effectiveness of the providers and the integrity of their results.  But mainly, we might be at a point where there ought to be a standard and a governing body to better guide the service providers and to better serve those that enlist the service.

And having reached this crucial point, device search engines do deserve a serious scrutiny.  For example, Ripple20 is a classic example of how this resource would have been handy for both those chasing the issues and unfortunately, to those hoping to negatively capitalize on it.  The software in focus appear to have had a very unconventional and possibly chaotic distribution model.  And to make it worse, used in health care devices, among others.  The struggle in hunting for affected devices is further covered in this article and this .  And this article talks about a national health cybersecurity standard but there might be a pressing need at a different level as well - a global one and in the area of device search engines.  That way, the results can be guaranteed as well as it can be guaranteed, to be comprehensive and accurate.

The current covid-19 situation has only gone to further accentuate the advantages of and need to better regulate device search engine use, for it to be useful to those leveraging it positively and deter the opposite.  It helped study how organizations are adapting to changes and how they are tweaking their environment to accommodate remote work needs, by studying the services and ports that are newly exposed in higher numbers, for example, the RDP port/service.  It appears, not too long ago, countries have started scanning their IP space, to get a handle on vulnerable devices in their geography.  There is an overlap in what they do and how a more disciplined device search engine space could help better streamline the process.

Lastly, a pressing need for autonomous providers from varied geographies, to keep us honest, cannot be stressed enough.  I remember reading about telegram, albeit in a very different context, and how they kept themselves honest and delivered on their commitment to their customers, by jumping through hoops and slipping through the gates, when that is what it took.  Do we have mavericks among us to be able to do that in this context and to keep us honest?  Because, among other things, playing stooges all the time is starting to get pretty damn boring.

I recently ran an application under OllyDbg and noticed a minor inconsistency, while debugging a rep prefixed instruction (Intel® processor).  When the debugger hits a breakpoint at a rep prefix'ed instruction, if I attempt to run past it (i.e., press F9), the debugger steps into the same instruction "n" number of times (each time I press F9), "n" being the initial content of ECX register, right before the instruction was first executed.  This is comparable to how an emulator would behave!  Instead of running past, if I step over that instruction (i.e., press F8), the debugger behaves the way one would expect and steps over to the next instruction.  I was wondering whether the inconsistency I am noticing is an oversight or a bug or the intended behavior.  OllyDbg folks are best placed to answer that!

This is a quick post to inform visual studio developer team of a very minor bug in their VS community edition 2015:

When I select a function name with an added space in the front and then click on F12 or Alt F12, to "Go to definition" or "Peek definition" for the selected text/function", I get a, "The current operator '(' is not overloaded" error.  When I chose the same function name without the space prefix, I don't encounter the same error and I am able to successfully get to the definition.  This is a minor bug, as demonstrated by the below demo as well.

Recently I encountered an exception while debugging an Intel® SGX powered enclave application.  Interesting enough, unlike classic environment, where the point of problem is usually apparent, there wasn't much I could glean from the debugger with this particular instance of the exception.  The call stack window was empty and the debugger didn't take me to the point of problem as it normally does.

This being an enclave application, as a first step, I wanted to find out where the exception was happening, as in, whether it was within the trusted environment or outside.  So, I installed a custom trusted exception handler, using Intel® SGX SDK provided sgx_register_exception_handler API and ran the same application.  The idea being, if the exception occurred within the trusted environment and if for some reason, the Intel® SGX Visual Studio add-on that handles the trusted debugging failed to capture the exception, I would be able to find out.  The trusted custom exception handler I installed didn't get invoked.  Based on that I could conclude that the trusted execution environment is unlikely to have been the triggering factor for this exception instance.

I then installed an exception handler within the untrusted application using vectored exception handling feature provided by Microsoft Win32 API AddVectoredExceptionHandler.  Sure enough I hit the exception handler the next time I ran the application.  I was then able to check whether the faulting address was within the enclave address range using Intel® SGX SDK provided sgx_is_within_enclave API, by invoking that API via the untrusted exception handler.

Admittedly, it was a developer error that caused the exception.  In this case, by way of an attempt to access an enclave address space address.  However, debuggers are designed to make it easier for developers to spot these developer errors.  What made the problem all the more non-obvious was that it was happening during thread creation time.  If the Intel® SGX Visual Studio add-on would include an exception handler to trap exceptions caused by access to trusted address space addresses, while running in untrusted context and provide more specific information, potentially along with information regarding the last OCALL or event that caused the transition from trusted context to untrusted, it can only make Intel® SGX applications development/porting all the more easier.  An aggregate of such minor additions can only positively encourage further adoption of the technology.

Following is a demonstration of the problem described above:

I recently encountered what appears to be a very minor bug in Visual Studio 2015 Community Edition.  I made some changes in a project I am working on, and navigated to the team explorer, to run a "diff" (i.e. invoke "Compare with Unmodified..." context menu) on a file I had changed.  I then tried to search for a string within the solution, while I had the "diff" window open.  The original file and thus the "diff" window file also happened to have the string being searched.  I navigated to the "Find Result 1" window that listed the search results.  I then used the "F8" shortcut to navigate through the search results, one after the other.  When I reached the result pertaining to the file that had its equivalent "diff" file open, I was taken to the "diff" file as opposed to the actual file containing the search result.  And once I reached that point, the "F8" shortcut stopped working and I could no more navigate through the rest of the search results using the "F8" shortcut.  I had to further navigate the results using the mouse, to point at and select the next search result within the "Find Result 1" window.

Admittedly, this is a very minor bug but at times this kind of minor bug provide a window into a different underlying issue.  And in this case, the fact that Visual Studio confuses between the temporary diff file and the actual file might be a clue as to there being potentially non obvious issues as well.  Nevertheless, thought Visual Studio team might be interested to know.

Following is a quick demo of the bug:

In an earlier post, I had talked about a potential design issue, along with a follow up on that here.  In the follow up, I had described how I couldn't reproduce the issue in practical ways.  It turned out, I was able to reproduce it with a different project.  The first demo below is a demonstration of that, along with how to get around the problem during build time.  But, as mentioned in the earlier follow up, it only pushes the problem to runtime.  The second demo below describes how to circumvent the issue during runtime as well.  Here are the conclusions, having investigated the issue - 

• There does appear to be a design issue as described in this post.​
• There are many ways to wrangle the compiler and linker to get past it.
• Based on how, when and whether the compiler/linker need to look for dependency symbols in the linked libraries, the problem may not even surface during build stage.

But, there does exist a design issue that comes in the way of implementing modular design and revisiting it as requested in the main post on this topic can only help.​​

Demo I :

​Demo II :

Below is a follow-up on a previously published post. In that, I talked about what I thought to be a design issue. I still consider it a design issue, although I can no more reproduce it in practical ways, surprising enough. I mentioned that as well in the preface to that post.

I wish I had recorded the issue then and as I was chasing it, and before concluding the design constraint that forced it. But, I didn't expect the issue to just disappear. So, I didn't record it then.  There are enough moving parts in this to suspect an accidental change to have positively impacted the problem, thus making it vanish. Also, this is the kind of issue where I would be more inclined to blame my own oversight, which I still suspect. However, I would more assertively say that with a connecting thread of change to pin to the issue. Failing that, I am unwilling to overlook the previous observations, the easiest thing to do, and because the problem appears to have disappeared. It is exactly this kind of magical and seemingly positive changes that are momentarily inexplicable that pops up again at crunch time. So, I figured I would record its current state. This can only help with a future brainstorming on this topic, perhaps at a later time and when feasible.
​
Following is a recording of the problem:​

[Following is an excerpt from conversation between Elsa Snow'ed-in, we will call [Elsa] and Enlightened Sock [Sock], discussing the zombie in her device.]

[Elsa]: Hello!  I am excited to start a conversation on a topic that seems to interest you and frustrate you at the same time.
[Sock]: Good to be here.

[Elsa]: So, tell us more about this project #prismnotes.
[Sock]: When I encounter technical issues that I find inexplicable, I am hoping to note it under #prismnotes.

[Elsa]: By technical issues, you mean, the zombie in your device that gives you grief?
[Sock]: It is a journal of technical issues I am unable to explain to myself.  Some of them could be oversight on my part.  Rest obviously inexplicable.

[Elsa]:  I find the name project #prismnotes interesting.  Is there an underlying connotation?
[Sock]: Prism is a three dimensional object that interest me.

[Elsa]: I understand.  But is it a light hearted take on something that could be more controversial?
[Sock]: It happens to be a polyhedron, a solid in three dimensions with flat polygonal faces, straight edges and sharp corners or vertices.

[Elsa]: <Annoying stream of giggles>  I have access to Wikipedia...  You haven't answered my question?
[Sock]: The word polyhedron comes from the classic greek as poly-(stem of "many") + -hedron (form of "base" or "seat").

[Elsa]: <Annoying stream of giggles> Alright.  Moving along.  Do you expect us to be having frequent conversations?  Because.... that could be fun... given how it's going thus far...
[Sock]: No.

[Elsa] : Good... Good <sign of relief>  Do you expect to be filing a lot under #prismnotes?
[Sock]: The plan is not to inundate.

[Elsa]: Ok.  Can you tell me why you are doing this then?
[Sock]: In future, I would like to avoid having to answer some obvious questions that the better breed won't bother asking.

[Elsa]: Like what...?  On the matter of timeline... activities... correlating it with output etc.?
[Sock]: It is purely for the benefit of a deep thinking community that prefer not to insult each others intelligence by asking the obvious questions while helping themselves to a better perception.  It is good, as a record, for posterity.

[Elsa]: Have you started on it yet?
[Sock]: I could have started sometime back.  My depth of perception hadn't broadened yet, plus I was worried about challenge to cerebral depth if I go down that path.

[Elsa]: Ok,  looking forward to it! <Fake giggles>  Bye.
[Sock]: Bye.