full-disclosure - Format String Vulnerabilities in Perl Programs

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

Date: Sun Dec  4 19:56:48 2005
From: coley at linus.mitre.org (Steven M. Christey)
Subject: Format String Vulnerabilities in Perl Programs

On Sat, 3 Dec 2005, Chris Umphress wrote:

> Almost all of the statements refer to a number of programming
> languages if thought is not put into the program. Security requires
> thought.

Agreed, but every once in a while we run across things that people don't
usually think about.

> >    The possibility of CRLF injection was theorized, but a casual
> >    investigation was not successful.
>
> \r\n ?? \x0d\x0a ??

This was 3 years ago and I don't remember the details, but I tried
something like \r\n, \\r\\n, etc.  It appears that the "\n" are converted
during initial interpretation, not execution.  I didn't look too deeply
into it.

However, I just realized that you might be able to feed a 0x0A value into
a "%c" specifier:

  $username = "%c";
  $score = 10;
  printf "USER = $username; SCORE = %03d\n", $score;

This produces:

  USER =
  ; SCORE = 000

> > **********************************************************************
> > 4. Some Discussion on Format Strings and the Taint Checker
> > **********************************************************************
>
> It shouldn't have to. As Linus Torvalds says -- You should think
> through your code rather than expecting a tool to find the problem for
> you [1].

Agreed as well.  However, security mechanisms are useful in the cases in
which the programmer still makes a mistake despite best efforts, so their
limitations are noteworthy.  This is roughly equivalent to the limitation
of canary-based overflow protection mechanisms.  They don't work in every
case.

> >   $fmt = <USER_INPUT>;
> >   printf("THIS IS A POTENTIALLY VULNERABLE $fmt FORMAT STRING\n");
>
> That is probably the closest thing to a feasible mistake for someone
> who is thinking about the code they are writing (IMO). If you aren't
> performing a string insertion of some kind, "print" is far better.
> While I do understand the argument to some degree, "print" is the most
> common way to display text (from my own experience, "print" usage is
> much more common in scripting languages than printf).

It's that way based on what I've seen, too, so maybe the problem appears
more rarely than it does in C.

With respect to programming languages in general, I would think that if
the language provides very flexible, easy-to-use ways of formatting
outputs - like Perl and PHP - then format string issues might be less
common, since there would be less need to use printf-style functions.  I
don't know Javascript/Java well at all, but they might be more susceptible
since it looks like a number of printf-style packages are available to
make up for the real (or perceived) lack of built-in formatting support.

- Steve