bugtraq - Re: Re: Gaim festival plugin exploit

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <867k2w2dxg.fsf@blue.stonehenge.com>
Date: 23 Oct 2003 08:04:27 -0700
From: merlyn@...nehenge.com (Randal L. Schwartz)
To: Brian Hatch <full-disclosure@...kr.org>
Cc: HCTITS Security Division <security@...ancentrictech.com>,
   bugtraq@...urityfocus.com, full-disclosure@...ts.netsys.com
Subject: Re: Re: Gaim festival plugin exploit

>>>>> "Brian" == Brian Hatch <full-disclosure@...kr.org> 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
planet.

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.

JUST LIKE I ALREADY FRICKIN SAID.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@...nehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html