Various *nix OSes Open To Format String Attacks

Numerous readers have pointed, as this unnamed correspondent does, to this CNET article: "There is an article on cnet claiming that both unix and linux systems contain security flaws, called 'format string' vulnerabilities, which allow hackers the ability to trick systems through command manipulation and subsequently run unauthorized applications."

Comments

But what do you do?

[Alan Shutko]

The base of the vulnerability is that people include format strings in their locale database. This has been a recommended practice, because it would let you restructure messages when you localize the strings.

For example, you might have a message "Cannot open file %s". When translating the message to another language, the grammar of the language might require placing words after the file ("annotcay ilefay %s openway"). This is easy to do if you translate the whole format string, but if you'd constructed it by strcat("Cannot open file ", file) the translator can't reorder the message.

But this makes you vulnerable because attackers can specify the locale database they'd like to use, making the format string something absurd like "%s%s%s%s%s%s", smashing the stack and opening the door to exploits.

Unfortunately, I haven't seen anyone give an alternative. The original advisories just say "This is bad coding practice, don't do it" but don't offer any alternatives and point to documents which RECOMMEND DOING EXACTLY THIS.

So, a question to all... how to you write your code so that it's flexible enough for translation, but not open to attack?

Credibility

[Nexx]

The wording of the article tells me that the guywho wrote it doesn't have a slightest clue what he is talking about, but wants to scre everyone in sight to death

Heard on NPR, quoting Jesse Ventura, the governor of Minnesota. He stated, and quite correctly, that many media outlets are no longer in the business of reporting the news, but instead, making the news. They're slaves to the almighty buck.

He went on to state that there's nothing wrong with being a slave to the almighty buck, but if they are, they should not be misleading consumers by stating that they're "journalists" and not "tabloid artists".

On the web, as with anywhere else, "consider the source". Many people no longer do this, but this is absolutely critical when judging the accuracy of any information, not limited to that shown in the news. Sensationalism in "professional" journalism is very much alive today as it were in the 1890's, when "yellow" journalism coursed through the pages of "credible" newspapers.

--

Not new

[imp]

This isn't that new. Most of the *BSD issues
have already been committed and are thus not vulnerable. Tehy make it sound a lot worse than
it really is.

Also, *ALL* Oses are impacted, since all oses have the sprintf-like functions.

Warner Losh
FreeBSD Security Officer.

Re:Hmmm...

[emerson]

You're not following Bugtraq closely enough then.

http://archives.ne ohapsis.com/archives/bugtraq/2000-08/0457.html describes a format string vulnerability (and sample exploit code) in the locale system of most Unixes; OpenBSD appears not to be vulnerable, and FreeBSD is not remotely exploitable, but all other major Unixes appear to be vulnerable.

This isn't FUD; the article is pretty dead-on.


--

Re:C specific, not unix specific

[mangino]

This is actually a problem in the gettext routine. It allows a person With a local account to create a custom locale that includes format strings inside the internationalization code. The answer is simple, drop the locale related variables from setuid environments. What was not mentioned in the article is that for the current cases, this requires a local account on the machine and setuid that doesn't drop the correct variables from the environment. If you don't use internationalized setuid programs, you should be okay.

Mike
--
Mike Mangino
Sr. Software Engineer, SubmitOrder.com

Taint mode solves this problem

[vectro]

Perl's 'taint mode' solves this problem very well. Basically all user input (enviornment, standard input, reading from files and network sockets, etc.) is considered 'tainted', and can't be used in an insecure manner (running commands, etc.) without a regular subexpression match.

Basically, what this means is that perl forces you to check that the input you were given is secure. This makes perl more secure than C in many ways.

For more information on taint mode and other security features in perl, see the perlsec manpage.

Unix specific? Yes and no.

[Forgotten]

First off, the CNet story is a crock written by a hack with just enough understanding of the subject to screw it up. Par for the CNet course.

There is a valid point made by the people suggesting that this problem is endemic to any software linked to the standard C library, or more specifically to software that abuses the printf() family of functions. This obviously isn't Unix-specific - the locale mechanism just happens to be the exploit that was described.

However, there *is* a gem of truth to the Unix vulnerability idea, and it's rooted in the power of the shell as well as the existence of (and overeliance on) the system(2) call. This is why the US Army moved their web servers from NT to (gasp) the "classic" Mac OS - not just because it offers no network services by default (this can trivially be accomplished on any OS), but because it doesn't have a command-line shell that's easy to exploit (note that I don't agree with their decision and would never deploy the non-Unix Mac OS for any production network server - also note that their assumption isn't even correct, because AppleScript is quite comparable to the Bourne shell and *can* be remotely invoked in some cases).

Part of the problem here is that we have come to rely on models for Unix network software that either need to put strings through the shell (and thus have to deal with baroque quoting issues) or can be tricked into doing so. CGIs are an example of this - it's now obvious that the CGI wasn't a particularly good choice for scalability *or* security. These issues do need to be addressed, so perhaps we can get a modicum of real use out of this latest CNet drivel.

Format Strings 101 (fixed)

[lamontg]

(Sorry for the duplicate, hit the fscking submit button when I meant to hit preview...)

The problem comes about when you accept user input and then send it to vsprintf(), setproctitle(), syslog() or similar C programs that accept format strings. The seemingly innocuous code usually looks something like this:

char buffer[1024];
[...]
sprintf(buffer, "some message: %s", hostile_user_input);
syslog(LOG_DEBUG, buffer);

Now an attacker can shove a string into the hostile_user_input variable like "%s%s%s%s" which will then be passed to syslog which whill execute:

syslog(LOG_DEBUG, "some message: %s%s%s%s");

Notice that this isn't a "valid" format string. It tends to do odd things since it goes looking for function arguments that aren't actually there. Clever construction of the hostile format string will lead to an exploit. This was used in the wu-ftpd remote setproctitle() exploit and the recent linux rpc.statd syslog() remote exploit.

All OSen which have code compiled from C and which use the vsprintf(), syslog(), setproctitle(), etc functions are potentially vulnerable to these attacks. There are undoubtably these kinds of vulnerabilities lurking within W2K somewhere...

Script Kiddies have known this for years

[spazimodo]

y 3l53 d0 j00 th1nk th3y r1t3 lyk3 th1s?



-Spazimodo

Fsck the millennium, we want it now.