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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
From: scottp at (Scott Phelps / Dreamwright Studios)
Subject: Re: Gaim festival plugin exploit

This is great, somebody is arguing Perl syntax with the guy who co-wrote the
llama book.

I don't come here for the security, but for the entertainment :)

-----Original Message-----
[] On Behalf Of Randal L.
Sent: Thursday, October 23, 2003 11:04 AM
To: Brian Hatch
Cc: HCTITS Security Division;;
Subject: Re: [Full-Disclosure] Re: Gaim festival plugin exploit

>>>>> "Brian" == Brian Hatch <> writes:

>> >> system("echo \"$string\" | /usr/bin/festival --tts");
>> Replace this with
>> open FEST, "|/usr/bin/festival --tts";
>> print FEST $string, "\n";
>> close FEST;
>> No shells involved.  Only DOS exploits and maybe the usual
>> C-language overflows in festival itself.

Brian> Well, no, that open does invoke a shell, albeit one with
Brian> no user input.

Excuse me.  No it doesn't.  I dare you to watch a trace of that
program and tell me if EVER a /bin/sh is invoked.  It doesn't.  It
forks, and calls festival directly.  Just a child.  No grandchild.  No
chance for a shell interpretation.

When the pipe-open is simple enough (no shell metachars) Perl goes
directly to the $PATH and figures out how to parse that string into
the argv[] and calls execve directly.

Please don't challenge such obvious Perl knowledge for
someone who has spent the past twelve years writing more Perl
documentation and teaching Perl more than anyone else on the

I'm sorry if I sound irate, but Perl and Security are my two
expert areas.  Sheesh.  Trust me on this one, OK?

Brian>   It's still better to 

Brian> 	pipe
Brian> 	fork
Brian> 	child exec explicitly
Brian> 	parent read pipe

That is *precisely* what this is doing, using the shortest
syntax known to man. :)

Brian> Newer perl can actually use list form in the 'file'
Brian> section for open, so you'd be able to use that to
Brian> avoid a shell in the open without writing the code
Brian> yourself.

Not needed.  This already avoids the shell.


Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<> <URL:>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See for onsite and open-enrollment Perl

Full-Disclosure - We believe in it.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3230 bytes
Desc: not available
Url :

Powered by blists - more mailing lists