Re^2: Searching for sprintf() bug exploit opportunities in core and CPAN modules

I agree with you. I think more is being made of this than it is. Sure, it's a bug, and needs to get fixed, but it's only dangerous in the same sense that eval $q->param('input') is dangerous.

I mean, no one is saying anything about how "~~pack~~unpack" can get you to read or write arbitrary memory locations. This is well known, by design, and is just as dangerous (if not moreso, because there's no intent to fix it!).

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

Comment on Re^2: Searching for sprintf() bug exploit opportunities in core and CPAN modules Download Code

Replies are listed 'Best First'.
Re^3: Searching for sprintf() bug exploit opportunities in core and CPAN modules by diotalevi (Canon) on Dec 03, 2005 at 00:11 UTC
pack() will only read from arbitrary memory. It won't write back. pack( "p", ... ) returns a pointer, unpack( "p", ... ) reads from a pointer. Anyway, I'm just noticing that this is an unexpected way to write to memory (or more likely just segfault). Prior to coming up with the list of references in the original post, I wasn't sure that some CGI module wasn't going to be using sprintf() or something and maybe then be a commonly accessible remote exploit. It turned out that there weren't all that many places that user data might actually go through a format. If anything, I'd imagine that Sys::Syslog would be biggest problem just because its easy to omit the format from the parameter list.	[reply]

Replies are listed 'Best First'.

Re^3: Searching for sprintf() bug exploit opportunities in core and CPAN modules
by diotalevi (Canon) on Dec 03, 2005 at 00:11 UTC

pack() will only read from arbitrary memory. It won't write back. pack( "p", ... ) returns a pointer, unpack( "p", ... ) reads from a pointer.

Anyway, I'm just noticing that this is an unexpected way to write to memory (or more likely just segfault). Prior to coming up with the list of references in the original post, I wasn't sure that some CGI module wasn't going to be using sprintf() or something and maybe then be a commonly accessible remote exploit. It turned out that there weren't all that many places that user data might actually go through a format. If anything, I'd imagine that Sys::Syslog would be biggest problem just because its easy to omit the format from the parameter list.

[reply]