Sure, the cause of the buffer overflow is obvious - there are limits on the length of path names and path name components. But, unlike on Unix, the potential error was nowhere checked or trapped, leading to the potential for exploits.

In this case Perl should definitely have a platform specific length check to avoid the bugginess of the underlying API leading to possible exploits in Perl code.

It doesn't (on this occasion) appear to be a CRT (C RunTime library) problem. Using

#include <stdlib.h>

int main( int argc, char**argv ) {
    int rc = 0;
    printf( "Using '%s'\n as an argument to system()\n", argv[1] );
    rc = system( argv[1] );
    printf( "Command returned: %d\n", rc );
    return 0;
}
[download]

built with msc and calling it with an argument of 256 'A's gives:

P:\test>system AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA.....
Using 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA...'
 as an argument to system()
'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA...AAA'
 is not recognized as an internal or external command, operable progra
+m or batch file.
Command returned: 1
[download]

Increasing the length to 300 'A's

P:\test>system AAAAAAAAAAAAAAAAAAAAAAAAAAA
Using 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA...AAA'
 as an argument to system()
The input line is too long.
Command returned: 1
[download]

---

Examine what is said, not who speaks.

"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail

The behaviour has been different for people under very similar circumstances. It is also very possible that Microsoft has noticed the underlying security flaw and that different patchsets will result in different behaviour from the same exact code.

My description of what it means to see the "illegal operation" error remains valid. The trick is whether it can be tickled just so as to get a working exploit. I never care to bet that it absolutely can't be done after that error shows up.

This program has performed an illegal operation in Windows means that it tried to execute something that wasn't a command.

I think you can also get that error by attempting to write to memory that isn't allocated to you (e.g., in case of a buffer overrunwild pointer). I can't prove it, though, and it's possible I'm mistaken.

Update: wild pointer is a much better example than buffer overrun of why this would happen.

---

;$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}} split//,".rekcah lreP rehtona tsuJ";$\=$;[-1]->();print

I just checked. You're right, my description was incomplete.

You can get that error from a large variety of interrupts and exceptions. The case that I described is when a normally working program has an illegal instruction because what was supposed to be code was overwritten (eg by a buffer overrun). But you can get the same error if you, for instance, attempt to access a memory address that isn't mapped.

In the event of a buffer overrun that overruns just slightly, it is far more likely that you would overwrite code than that you would access memory outside of what is mapped. But missing the buffer due to a programming bug could easily be accessing wild memory addresses, giving the same error through a wildly different cause.