in reply to ActivePerl crasher

Intriguing. All these crash AS809 

perl -e"$c='A'x256; system $x;"
perl -e"$c='A'x256; `$x;`"
perl -e"$c='A'x256; qx[$x;]"

[download]

with The instruction at '0x........' referenced memory at "0x41414141". The memory could not be written. Which makes look like an CRT or OS problem.

But then, if you replace the variable containing the 256 'A's with a constant string. perl -e"system 'AAA...AAA'" etc.

None of them crash, they just report 

'AAA...AAA' 
is not recognized as an internal or external command, operable program
+ or batch file.

[download]

Which would tend to indicate that the segfault is a perl (build) problem.

Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail

Replies are listed 'Best First'.
Re^2: ActivePerl crasher
by saskaqueer (Friar) on May 18, 2004 at 03:01 UTC
    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]
[reply]
[d/l]
[select]
Re: Re: ActivePerl crasher
by zude (Scribe) on May 19, 2004 at 17:38 UTC
    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.
[reply]

      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
[reply]
[d/l]

In Section Meditations