$ uname -s
Linux
$ perl -we "system 'A'x256"
Can't exec "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
+AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
+AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
+AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA": File n
+ame too long at -e line 1.
$
[download]

Abigail

Right, but this is crash, not error.

The big deal is that the error message indicates an exploitable bug. This program has performed an illegal operation in Windows means that it tried to execute something that wasn't a command. That usually happens because there was a buffer overflow and Windows tried to execute something that wasn't valid machine code. However if you found what length the buffer overflow happens at and insert something that is valid machine code, arbitrary code can get executed.

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

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

But then, if you replace the variable containing the 256 'A's with a constant string.... none of them crash, they just report '...'.

Actually, my version of the story varies a little. When assigning the command to execute as a variable, the errors have various boundaries. These boundaries differ depending on whether we use 'x' to multiply the value ($foo = 'A' x 256) or whether we assign a constant string ($foo = 'A...A'; # where length($foo) == 256). Very strange behaviour. I've gotten 3 different responses depending on length and method used. The regular "unrecognized command", the "The input line is too long" report error, and the dreaded "memory could not be written" fatal error.

I am building a list of the boundaries and results that I will post when I'm done. Sorry, this is getting too mucked up for me. Here's yet another case of the real freaky:

C:\>perl
$foo = 'A' x 255; system $foo;
$foo = 'A' x 256; system $foo;
^Z
'AAA ...<cut>... AAA' is not recognized as an internal
or external command, operable program or batch file.
Free to wrong pool 222810 not 41410065 at - line 2.

# We now get a fatal popup error with the lovely "Perl
# Command Line Interpreter has encountered a problem
# and needs to close.  We are sorry for the inconvenience."
[download]

I didn't see this until just now. 0x41414141 of course is 'AAAA', you overwrote the return address on the stack, therefore this IS exploitable.

Oh yes, totally. The only question is what code is responsible.

I tracked it backwards from the point of failure (at which point the stack is completely screwed up) and found that the error definitely occurs somwhere after perl_do_span() calls win32_spawnvp() and before it return from the former.

Tracing it through at the binary level, CreateProcess() has been called and returned. As have GetExitCodeProcess(), a couple of calls to CloseHandle() to free up the PROCESS_INFORMATION structure. and at that point, the stack appears coherent. After that, win32_spawnvp makes a couple of calls to Perl_safesysfree() and one to MSCRT::strrchr() before trying to return to Perl_do_spawnvp() by which time the stack is corrupted.

The cynic in me guesses that it is the call to strrchr(), possibly looking for a null terminating byte that isn't found that is responsible, but that is pure speculation. Even if that is the cause, working out whether the CRT is responsible or the code that calls it is very difficult working at the machine code level, and I don't have a debug build of the code.

Either way, it doesn't seem (to me) to be the OS, but it will take somebody with better knowledge of the perl sources and better tools than I, to really make the determination.

---

Examine what is said, not who speaks.

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