Slashdot Mirror
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."
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!
The Doctor What (KF6VNC)
It's very, very simple.
/etc directory, with programs which can read a config from /etc and a user specific location.
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
--
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
One plus is that taint mode is automatically activated in any setuid perl script.
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.
--- "So THAT's what an invisible barrier looks like!" - Time Bandits
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?
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
Personally I love
Sure there are things that are BS on
--- Juggle juggle@hitesman.com
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.
--
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
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...
"We can confirm that Debian does *not* ship the version with the trojan horse. Our version predates it." [CA-2002-28]
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.
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.
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).
*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).
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....
Feed The Need[goatse.cx]
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.
This is not a problem with C, this is a problem with the OS.
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"?
/. was supposed to be getting?
For that matter, how about all the new filtering features that
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
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
www.dedserius.com
VB != VisualBasic
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()...
main(O){10<putchar(4^--O?77-(15&5128 >>4*O):10)&&main(2+O);}
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, 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.
Eh...
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
this is my sig.
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
---
I'm going to dump all my karma in the can for this.
.. "Windows Open To Format String Attacks". I imagine the response would be a slew of crude comments, and downright flames about microsoft incompitance.
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
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
this is my sig.
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.
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:
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.
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.
(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.
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.
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?
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.
------ Curiosity killed the cat. {satisfaction brought it back | it didn't die ignorant | lack of it is killing mankind
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?
====
Crudely Drawn Games
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
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...
The ways of the underworld are perfect. They may not be questioned.
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.
---
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
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...
* And remember, it's spelled N-e-t-s-c-a-p-e, but it's pronounced "Mozilla."
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.
What's a sig?
yeah, only 1263 exploits will work instead of 1264...
IBM had PL/1, with syntax worse than JOSS,
And everywhere the language went, it was a total loss...
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).
-- Ed Avis ed@membled.com
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.
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.
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
I have used my fish to translate this from the language of reactionary journalists to something an intelligent person will understand:
/. 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.
/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
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
Dacels Jewelers can't be trusted.
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...
> (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.
The crimes of eBay are a disgrace to it's pig latin heritage!
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
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.
Everybody Lies. But it doesn't matter since nobody listens.
strcpy(buf, "first post"); printf("%s\n", buf);
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.
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!
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.
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...
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.
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.
If you need web hosting, you could do worse than here
y 3l53 d0 j00 th1nk th3y r1t3 lyk3 th1s?
-Spazimodo
Fsck the millennium, we want it now.
Fsck the millennium, we want it now.
Millennium Crisis Line: 0890 900 2000 [calls cost 50p/min]
they don't know meaning
but script kiddies do rejoice
more cracked boxes
Further information on this topic may be found here.
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.
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.
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?