Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister
 
PerlMonks  

Searching for sprintf() bug exploit opportunities in core and CPAN modules

by diotalevi (Canon)
on Dec 02, 2005 at 07:48 UTC ( [id://513527]=perlmeditation: print w/replies, xml ) Need Help??

There is an exploitable integer overflow in the sprintf/printf format handling code. The following are the results of auditing my 5.8.7's lib and site_lib directories. I used the module at Experimental sprintf overflow bug detector to automatically locate all calls to printf and sprintf that might potentially be exploitable.

I only audited the CPAN modules that are in my site-lib directory. You may be using other modules which might have more serious issues.

Potentially exploitable code in core perl modules.

5.8.7/CPAN.pm line 514. 5.8.7/CPAN.pm line 547. checklock() exploitable via the lockfile name and the hostname and pid in the lock file. 5.8.7/CPAN.pm line 892. tidyup() exploitable by getting it to attempt to tidy up a directory named something bad. 5.8.7/ExtUtils/Command/MM.pm line 194. perllocal_install() both parameters are exploitable. This is very low risk, the function typically accepts just developer input on the command line. 5.8.7/ExtUtils/Constant/Base.pm line 483. 5.8.7/ExtUtils/Constant/Base.pm line 552. The internal function switch_clause() accepts some data that's exploitable. This is used when generating XS code from constants. I think it's very unlikely this is really exploitable in any meaningful way. You'd have to accept unsafe source code for this to be a problem. 5.8.7/i686-linux/Sys/Syslog.pm line 321. syslog() The second parameter is passed largely unchanged into sprintf(). 5.8.7/Test/Harness.pm line 710. _dubious_return appears to interpolate some information which might come from tests its just run. I'm not sure if this accepts external data or not - I didn't trace it all the way through. 5.8.7/Hash/Util.pm line 85. lock_keys( @valid_keys ). If a hash is locked, a list of valid keys is passed, and the hash contains a key which is invalid under the rules, the invalid hash key is interpolated into the sprintf expression. 5.8.7/Locale/Maketext.pm line 85. Locale::Maketext::sprintf() is exploitable. 5.8.7/Tie/Handle.pm line 156. The default PRINTF function is exploitable. 5.8.7/i686-linux/IO/Handle.pm line 405. The ->printf method is exploitable. 5.8.7/Benchmark.pm line 594. 5.8.7/Benchmark.pm line 596. 5.8.7/Benchmark.pm line 598. 5.8.7/Benchmark.pm line 600. The first and third arguments of timestr() are exploitable but this isn't going to ever accept user input so it isn't really exploitable. 5.8.7/Benchmark.pm line 946. The first argument of timeit() is exploitable if $Benchmark::Debug is true. Its unlikely that parameter is ever open to user input so it probably isn't exploitable. 5.8.7/File/Temp.pm line 686. _is_safe( X, _ ) is exploitable in the first argument which is a directory name. Perhaps this is called on a potential directory for containing the temp file. The attacker might name the directory using an exploitable name. 5.8.7/Unicode/UCD.pm line 218. The entity is looked up in UnicodeData.txt. The entry is interpolated. This function is exploitable if the source file can be edited. 5.8.7/Pod/Perldoc.pm line 399. The $0 variable is interpolated. 5.8.7/CPAN.pm line 2744. The apparently unused hosthardest() interpolates hostnames. This is probably safe.

Safe uses of sprintf/printf that were reported in the automatic audit.

5.8.7/CGI/Util.pm 5.8.7/overload.pm line 93. 5.8.7/Math/Complex.pm line 1378. 5.8.7/Math/Complex.pm line 1392. 5.8.7/Math/Complex.pm line 1433. 5.8.7/Math/Complex.pm line 1462. 5.8.7/Math/Complex.pm line 1463. 5.8.7/Test/More.pm line 786. 5.8.7/Test/Builder.pm line 592. 5.8.7/Test/Builder.pm line 763. 5.8.7/Test/Builder.pm line 830. 5.8.7/Test/Harness.pm line 764. site_perl/5.8.7/Pod/Simple/RTF.pm line 292. 5.8.7/CPAN.pm line 1717. 5.8.7/CPAN.pm line 1739. 5.8.7/CPAN.pm line 1990. 5.8.7/CPAN.pm line 5284. 5.8.7/CPAN.pm line 5297. 5.8.7/CPAN.pm line 5305. 5.8.7/CPAN.pm line 5307. 5.8.7/CPAN.pm line 5322. 5.8.7/CPAN.pm line 5380. 5.8.7/CPAN.pm line 5385. 5.8.7/CPAN.pm line 5387. 5.8.7/CPAN.pm line 5389. All of these places threw warnings but are utterly safe.

Potentially exploitable CPAN modules.

Data/Dump/Streamer.pm line 1260. Data() interpolates $self->{style}{eclipsename}. This is probably not exploitable. Net/SSL.pm line 261. Net::SSL::printf() is potentially exploitable. Sniffer/Connection.pm line 101. handle_packet() might be unsafe. DBI.pm line 1068. data_string_diff(), maybe, under some strange conditions involving utf8 strings. DBI/PurePerl.pm line 650. FETCH() interpolates unrecognized attributes. This probably means the attribute name is exploitable. This requires a tied object and I'm not sure anything actually uses that. Is this even used? AppConfig/State.pm line 723. The ->_error method interpolates all error messages. This is likely exploitable. AppConfig/CGI.pm line 104. AppConfig/File.pm line 99. I couldn't see where the input, $format comes from. I get the impression that the data has a reasonable default and is otherwise probably programmer controlled. I suspect this isn't exploitable.

These warnings are likely to be ignorable.

DateTime/TimeZone.pm line 321. DateTime/TimeZone/OlsonDB.pm line 374. DateTime/TimeZone/OlsonDB.pm line 605. If the ->format method of some objects can be subverted, this might be exploitable. That's probably really unlikely. DBI/DBD.pm line 2824. DBI/DBD/Metadata.pm line 403. DBI/DBD/Metadata.pm line 472. DBI/Profile.pm line 583. DBI/ProfileData.pm line 550. DBI/ProfileData.pm line 558. DBI/ProfileData.pm line 580. DBI/ProfileData.pm line 613. DBI/PurePerl.pm line 609. HTML/Display/TempFile.pm line 39. Module/Build/Base.pm line 347. write() interpolates the module name. Its really unlikely to be a problem. Net/DNS/RR/NSAP.pm line 50. Net/DNS/RR/NSAP.pm line 51. Net/DNS/RR/NSAP.pm line 52. Net/DNS/RR/NSAP.pm line 53. Net/DNS/RR/NSAP.pm line 54. Net/HTTP/Methods.pm line 188. Test/Pod/Coverage.pm line 148. Text/Reform.pm line 176. Text/Table.pm line 394. YAML/Error.pm line 16.

Here's a bunch of warnings that I didn't check. I got tired and went to sleep.

Devel/Cover/DB.pm line 349. Devel/Cover/DB.pm line 353. Devel/Cover/DB.pm line 354. Devel/Cover/DB.pm line 363. Devel/Cover/DB.pm line 367. Devel/Cover/Report/Html_minimal.pm line 205. Devel/Cover/Report/Html_minimal.pm line 576. Devel/Cover/Report/Html_minimal.pm line 618. Devel/Cover/Report/Html_minimal.pm line 658. Devel/Cover/Report/Sort.pm line 43. Devel/Cover/Report/Text.pm line 120. Devel/Cover/Report/Text.pm line 143. Devel/Cover/Report/Text.pm line 144. Devel/Cover/Report/Text.pm line 151. Devel/Cover/Report/Text.pm line 201. Devel/Cover/Report/Text.pm line 202. Devel/Cover/Report/Text.pm line 204. Devel/Cover/Report/Text.pm line 250. Devel/Cover/Report/Text.pm line 251. Devel/Cover/Report/Text.pm line 256. Devel/Cover/Report/Text.pm line 64. Devel/Cover/Report/Text2.pm line 128. Devel/Cover/Report/Text2.pm line 90. Kwiki/Theme.pm line 27. Kwiki/Theme.pm line 32. Kwiki/Theme.pm line 41. Kwiki/Theme.pm line 54. Pod/Simple/HTML.pm line 488. Pod/Simple/RTF.pm line 292. Pod/Simple/TiedOutFH.pm line 52. Smart/Comments.pm line 193. Smart/Comments.pm line 235. Spiffy.pm line 217. Spiffy.pm line 219. Spiffy.pm line 221. Spiffy.pm line 222. Spiffy.pm line 223. Spiffy.pm line 225. Spoon/Command.pm line 55. Template/Context.pm line 877. Template/Context.pm line 888. Template/Context.pm line 890. Template/Filters.pm line 231. Template/Filters.pm line 236. Template/Filters.pm line 240. Template/Filters.pm line 246. Template/Filters.pm line 250. Template/Filters.pm line 416. Template/Parser.pm line 901. Template/Plugin/Format.pm line 51. Template/Plugin/String.pm line 228. Template/Plugins.pm line 267. Template/Plugins.pm line 274. Template/Plugins.pm line 278. Template/Plugins.pm line 279. Template/Plugins.pm line 280. Template/Provider.pm line 940. Template/Provider.pm line 941. Template/Provider.pm line 945. Template/Provider.pm line 947. Template/Provider.pm line 953. Template/Provider.pm line 959. Template/Stash.pm line 856. Template/Stash/Context.pm line 655.

Replies are listed 'Best First'.
Re: Searching for sprintf() bug exploit opportunities in core and CPAN modules
by thor (Priest) on Dec 02, 2005 at 12:35 UTC
    Alright...time for me to admit my ineptitude. Whenever I see stuff like this, I can usually follow only for a little bit. In this case, I followed the link to the advisory and understand that if you put a length specifier larger than MAX_INT in a format string, something bad happens. After that, though, I get a bit lost in their use of gdb to "demonstrate" the bug. Is there some way to dumb it down for a guy like me without providing something for script kiddies?

    thor

    The only easy day was yesterday

Re: Searching for sprintf() bug exploit opportunities in core and CPAN modules
by radiantmatrix (Parson) on Dec 02, 2005 at 19:11 UTC

    If I understand this correctly, the only way to exploit this is if code uses tainted input inside the format parameter of one of Perl's printf family of functions.

    Granted, this is still a bug, and will have to be patched; but it seems like this is only an issue if code is already using a practice known to carry security risks. Or am I missing something?

    <-radiant.matrix->
    A collection of thoughts and links from the minds of geeks
    The Code that can be seen is not the true Code
    "In any sufficiently large group of people, most are idiots" - Kaa's Law
      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 "packunpack" 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.

        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.

Re: Searching for sprintf() bug exploit opportunities in core and CPAN modules
by zshzn (Hermit) on Dec 02, 2005 at 15:51 UTC
    I'm very concerned about this. Red flags popped up in my mind when I saw the original syslog() vulnerability. Even with a quick patch to Perl_sv_vcatpvfn and more pertinent security checking, this could hound Perl and seriously damage Perl's security reputation. We need to take this as seriously as possible.
      I'm very concerned about this.
      Don't. It isn't that the world is falling apart.
      Red flags popped up in my mind when I saw the original syslog() vulnerability. Even with a quick patch to Perl_sv_vcatpvfn and more pertinent security checking, this could hound Perl and seriously damage Perl's security reputation.
      Oh, come on. syslog isn't more damaging to your system than rm is. What you should be careful about is passing user input as the second argument to syslog (and then only if you're running under a different ID than the user, or if the user is from the outside). Now, this is possible, but not something that ought to be common.

      Care should be taken, yes. But it's not a disaster.

      Perl --((8:>*
Re: Searching for sprintf() bug exploit opportunities in core and CPAN modules
by spiritway (Vicar) on Dec 09, 2005 at 05:49 UTC

    It seems to me that the problem isn't so much with Perl itself, as with the printf/sprintf functions. Wouldn't the same problem exist in C, as in Perl?

      No. Perl has its own sprintf() function. This bug is unique to perl. Patches have just been released for a variety of perl versions.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://513527]
Approved by Corion
Front-paged by Corion
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others browsing the Monastery: (2)
As of 2024-04-26 04:13 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found