Posted by
michael
on from the sauce-for-the-gander dept.
SirTimbly writes: "CNET is reporting that there is a buffer overflow problem with zlib in linux, which is used for network compression. Supposedly, someone could remotely cause a buffer overflow through mozilla, X11 and many other programs." The advisory from Red Hat is available.
Re:more info please
by
Anonymous Coward
·
· Score: 2, Informative
and the slashdot headline is braindead.
Its not a buffer overrun. its a double free. much harder to exploit, but still possible, so you should patch ASAP.
Re:more info please
by
mestar
·
· Score: 2, Insightful
Except in all those statically linked versions in who knows how many programs.
Re:more info please
by
Anonymous Coward
·
· Score: 2, Funny
Its not a buffer overrun. its a double free.
double free as in beer, or double free as in speech? Is the double free covered by the double GPL?
Re:more info please
by
ncc74656
·
· Score: 3, Informative
why the fsck would you statically link in zlib?
Um...because that's the way nearly every package that uses zlib links it? For instance, OpenSSH AFAIK will only statically link it (so if you rebuilt OpenSSH last week to fix this hole, you get to rebuild it again:-) ).
(I'm rebuilding OpenSSH on the work machines right now...I checked to see if it would link to libz.so, but it seems to only want libz.a.)
This is most assuredly NOT true. There is no reason to link at compile time when you can at runtime, so no one does, with the exception of executables in/bin and/sbin.
Unless you are writing a program to be as secure as possible and you are paranoid that somebody can substitute the shared libraries for trojaned copies.
why in the great ghost's name was this moderated as INFORMATIVE? oy! one minute i'm modded a 'troll' for something i thought was observant and humorous, and the next minute i'm modded 'informative' for something with zero content. moderation has some weird side effects.
zlib is not os dependent. Many Windows based products/projects use it as well. Is there some linux specific issues related to this overflow issue?... or is it just a headline hype thing
Credit where credit is due...
by
ubiquitin
·
· Score: 4, Interesting
Re:Credit where credit is due...
by
weave
·
· Score: 2
Interesting, so a coder inside Redhat finds it, fixes it, releases a fix.
Here's an exercise, and I don't know the answer. But of all the security alerts released by linux vendors and microsoft, what percentage of each is the result of an internal discovery versus someone outside reporting it and the vendor having to make a fix?
Dumb security question
by
wrinkledshirt
·
· Score: 4, Interesting
On the stuff I've been reading about finding and fixing buffer overflows, it seems like it's generally not too hard to spot where these things could potentially happen.
My question is this: How feasible would it be for someone to take a computer and have it do nothing but pattern-matching through all the source code in a typical Linux distribution, looking specifically for problem areas like these? Obviously we couldn't rely on it as a foolproof audit, but has something like this ever been considered?
--
--------
Bleah! Heh heh heh... BLEAH BLEAH!!! Ha ha ha ha...
Re:Dumb security question
by
SirSlud
·
· Score: 5, Interesting
Some software packages do this.. purify, etc. They're pretty expensive tho. The problem is that the logic that results in a buffer overflow error can be VERY complicated, and so its extremely difficult to spot sometimes even for the seasoned developer, nevermind a clever regex.
On the flip side, finding lots of memcpy's instead of strncpy might help you find the 'dumb' overflow bugs, but one would hope those arn't the ones we're most concerned about.:P Mostly, when copying and moving and generally playing with memory, if you spot functions without buffer limit or max byte limit arguments, you *might* be openening yourself up for trouble. Unfortunately, as I said, those are the easy ones.:) In reality, buffer overflow errors (and off-by-one bugs generally follow the 'simple errors can result from terribly complicated logic' construct of buffer overflow bugs) can be extremely difficult to spot if your input parsing/copying/moving mechanism is non-trivial.
-- "Old man yells at systemd"
Re:Dumb security question
by
Kamel+Jockey
·
· Score: 2, Interesting
How feasible would it be for someone to take a computer and have it do nothing but pattern-matching through all the source code in a typical Linux distribution...
A pattern matched theoretically could work (you would need some pretty bitchin' patterns though). However, what will definitly work is a meta-compiler which explicity looks for these problems in code. The most straightforward way to implement this is to use some sort of logic programming language (e.g., SML, Prolog, etc.) to act as a code-verifier, to prove (not just test, but actually prove in a mathematical sense). A meta-compiler could check to see that all malloc's are freed, all new's deleted, all bounds checking is enforced, etc. It is a very intensive process though, but because of these of which parsers can be written which convert code into a universally understandable syntax (independent of whitespace, coding style, etc., note that this is done by all compilers), this could be done.
Of course, the most effective way to solve this problem is to ensure that code is reviewed by someone other than the author so that these kinds of problems can be fixed.
-- In case of fire, do not use elevator. Use water!
Re:Dumb security question
by
Carnage4Life
·
· Score: 4, Informative
On the stuff I've been reading about finding and fixing buffer overflows, it seems like it's generally not too hard to spot where these things could potentially happen.
From this statement I assume you are not a programmer. Buffer overflows caused by using known unsafe library functions (e.g. strcpy, strcat, gets, etc.) can be handled by simple pattern matching but actually investigating the code to make sure every memory/array access does not go out of bounds is not a simple pattern matching problem.
Re:Dumb security question
by
frantzdb
·
· Score: 2
My understanding is that going through source to find possible run-time bugs is often not computable. Certainally you could find some things (x = *NULL will always fail, for instance, and while(1) will never halt), but lots of problems would never be found. A better solution would be to use a higher-level language so you don't have to worry about allocating and freeing memory, overrunning arrays, etc.
--Ben
Re:Dumb security question
by
jilles
·
· Score: 3, Insightful
The whole issue is not to use insecure languages like C. Such languages allow all sorts of memory manipulation and typically depends on the programmer to secure. The situation is made worse by the lack of something pretty essential: good libraries for string manipulation. While 3rd party libraries are available you can't assume these to be present so many developers still use char*.
Code reviews help, testing helps, good programming helps. But neither of these practices has succeeded in eliminating this type of bugs. It is just not good enough, witness a zillion bugs and security breaches on all major OSes (including the ones deemed secure, and yes I am talking about BSD) throughout the last decade. These OSes only differ in how the issues are dealt with. The occurance of the issue is a fact of life for all of them.
There's no C developer that can claim his program is completely free of buffer overflows (many foolishly do however). There may be some undetected errors in the program, the progrm may depend on third party code that contains bugs (e.g. the compiler or one of the standard libraries). Most likely bugs in all three categories are present.
Automatic checks are indeed the solution to the problem and modern languages build these checks into the run-time environment, where they belong. Buffer overflows are a non-issue in Java, for instance. The exception of this is native code and the JVM itself (written in C).
To eliminate buffer overflows, getting rid of the C legacy is the only solution. Java is probably too controversial as an alternative right now (though arguably it is quite up to the task as far as server side development is concerned) but there are other alternatives. Rebuilding serverside services like ftp, dns, ssh, smtp, pop, etc. is mandatory since each of these services has widely used C implementations that are frequently plagued by buffer overflows. The only way to guarantee that there are none left is to reimplement them.
--
Jilles
Re:Dumb security question
by
iabervon
·
· Score: 2
It would be possible to find occurences of known common mistakes in different packages automatically, and to find instances of a known error throughout a large project. There is work on doing this with the linux kernel, where a group has turned up hundreds of potentially unsafe usages (mostly DoS-type, mostly in drivers).
This particular problem is not actually a buffer overflow at all, it turns out, and is more subtle.
There are commercial programs which can find this sort of error, assuming it actually happens while running an instrumented version of the code. These programs are in the expensive commercial development tool price range (order $10k), though, and very difficult to write.
Another possibility is to build and run the program under a virtual machine which checks these things; for example, if you turn your C into Java and run it, it shouldn't throw any out-of-bounds exceptions, or it indicates that your C wasn't checking array bounds. There isn't a C virtual machine (that I know of), though.
It'd be next to impossible to detect a second free() of some chunk of code because machines are horrible at guessing what a programmer meant to do, rather than what they did. There are many tools available to diagnose memory problems, but they are slow and must be monitoring the code while it's running to do any good; to boot, they proabably won't find errors under normal program use. Besides, isn't this the C programmer's creed (the computer does what I tell it to do)? Well, zlib is doing exactly what the C programmer told it to do.
>the progrm may depend on third party code that contains bugs
.. or your 'non insecure language' runtime could contain bugs (as you point out.) At some point, the machine gets instructions, and while safe languages might cut down on the number of 'dumb' overflow bugs, the simple fact remains that overflow bugs will _always_ exist.
Education over technological safegaurds (I could just see the next generation of programmers: 'buffer what?').. otherwise, you rely on something you 'assume' is safe, but isn't neccessarily so.
All of this is notwithstanding the question: is a buffer overflow error in a platform that has 100% deployment better than lots of programs here and there getting their native buffer overflow bugs discovered? Interesting question unto itself...
Also, remember that performance requirements of core services (ftp, dns) have always outstripped performance supply. There will always be a need for languages that are 'closer to the cpu', in order to extract all possible performence to meet demand, and those will always be insecure.
Sure, client side run-once apps benifit greatly from safe languages, but there will always been a need for unsafe languages. To that end, I'd advocate pushing for a higher respect of 'safe' function use in code, by changing a developers' attitudes from 'ah, what the hell, i'm too lazy to use the safe func' to, 'if a safe func exists, use it or die'. Or writing safe wrappers to unsafe funcs, and having a policy saying you simply are not allowed to side-step the safe prototype.
I really can't imagine justifying the additional cost & perfornace hit of safe platforms with the laziness and 'infailability' of coders. If I were the one with my hands on the purse string, I'd understand that bugs will *always* exist (as to avoid putting all my proverbial eggs in one code base, which is probably the biggest problem facing our eceonomy's reliance in software stability and security), and make sure I have developers that understand how to minimize the possibility of producing code with these types of errors.
Also, don't forget.. a problem without a buffer overflow bug is still exploitable through a veritable infinitum of poor design choices, so are the benifits of nearly eliminating the possibility of buffer overflow bugs and memory related exploits truely worth the performance hit for critical systems with high load and a perf demand that almost always outstrips perf supply?
.. which is all a long winded way of saying, sure, your approach works for many cases, but it sounds like yet another case of someone with a hammer trying to make everything look like a nail.:)
These are the standard excuses I've been hearing for years. The amount of buffer flow related security issues has been a fact of life during all these years so obviously relying on programmer discipline/skill won't get us anywhere. It has never been a solution and it will never be a solution.
The JVM indeed has the problem that it is implemented in C which involves the risk of it having buffer overflows (and other C related bugs). However you can't introduce new bufferflows by programming in Java and the jvm could theoratically be reimplemented in a language that has a bit more elaborate memory protection.
Indeed bug free programs don't exist. However, minimizing the damage does help. The wide majority of programs implemented in C that we depend on might just as well be implemented in a more safe language. This includes large parts of the kernel and device drivers. I'd say it is time to give a bit more priority to security. In principle, if security is of any concern, the use of C should be avoided since it involves unnecesary risks.
The reason C is still being used is programmer lazyness. They are too lazy to learn/invent better languages (just like they are too lazy to adopt the code practices you suggest). The buffer overflow issue is so stupid, a simple run-time check completely eliminates it.
My suggestion simply is to stop developing in C. Stop new development in C, keep maintaining the old stuff and use more modern languages for new development. It can't be that hard, we can start with the smaller stuff like bind, openssh or telnet. I've seen well performing servers of all kinds written in Java. If needed, there are more lightweight languages than Java that are still secure.Most of the stuff that runs ontop of a linux kernel currently implemented in C (and therefore a security risk) could be implemented in C.
--
Jilles
Re:Dumb security question
by
UnknownSoldier
·
· Score: 2, Interesting
> Automatic checks are indeed the solution
Not for the embedded market, and consoles! I'm a console (games) programmer. All those little checks *ADD* up. Checks should be at the *programmer's descretion*, not at the whim of a compiler or language.
> to the problem and modern languages build these checks into the run-time environment, where they belong.
And you're completely ignoring the cost (performance) of doing so! For a debug build, yes, I love having extra checks, but for a full optimization build, NO. The performance cost is too high. There is a reason you have them in a debug build -- to write your code properly (robustfully) the 1st time, so you don't need the extra checking later.
> To eliminate buffer overflows, getting rid of the C legacy is the only solution.
Now you're trolling. You can write safe code in any language. Likewise you can write bad code in any language. Languages are *not* the silver bullet to the problem, but you for whatever reason think they are.
Insure (was Insight) does a tremendous job of this. I've been using Insure (used to be called Insight) for many years, and it can find all sorts of runtime problems. Of course, doing all the runtime checks is slow and takes time, but the savings in development time are awesome.
I am just a satisfied customer, and have no relationship with the company.
Re:Dumb security question
by
Steveftoth
·
· Score: 2
As far as you are concerned, everyone should also know everything about the enviroment they are programming in. They should probably know everything there is to know about a computer and such before programming. The point of java, Python and other languages is that they allow someone who doesn't understand what is really going on with a computer to program it. kinda like an automatic transmission helps you drive a car. C is a great language because it allows you to have as much performance as you want, while allowing you to also make versions that do extra checks and debug easily. IF anything, maybe it should be by default that C does bounds checking and garbage collecting and whatnot. Then you can turn it off when you make an EXPERT build of your program. C's main problem in my mind is that is makes it too easy to write bad code. One feature of C++ that I think can be bad is the assert statement. I've seen people write code that has critical side effects in assert statements, so that it only works in debug mode. Now you say, that's just a stupid programmer, but shouldn't the compiler and language design help to stop these kinds of stupid errors?
Your points on minimizing the damage are duly noted.
However, passing data from safe languages to unsafe libs (think php -> gtk) can still exploit subsystems which WILL have to be written in unsafe languages.
Then you're stuck saying that someday all these things will be written in safe languages, which is absolutely untrue. You simply do not sacrifice possible performance in core systems if its available.
Just as you say that relying on programmer discipline (I prefer to think of it as responsibility and education), neither will writing everything in 'safe' languages be. There will always be a demand to eek out the last bit of performance possible, and as such, checking for buffer overflows is such a cost.
We may simply disagree that at some point, being safe & higher performance can go hand in hand. I think that they both have their places, but make no mistake, higher performance will always result in less 'safe' development platforms, and thus relying on everyone switching to safe languages is just as faulty as relying on programmers to be perfect.
My point was that since neither are going to happen outright, the case is to pick and choose: those who need the performance (or dont believe your benchmarks, for instance... soley for the sake of argument) will gladly take the less safe platform, but must understand and respect these types of exploits, and those who need to be able to free up having to be responsible about memory, and focusing on appropriate enviornments where speed is non critical: servers, clients, etc.
And just to play devils advocate: at some point, at vm talks to an OS. OSes are pretty big, and lots of people work on them. So saying, 'forget bufferoverflows, they dont have to happen' is untrue. I do c/c++/perl/php/java... every tool for its job. Trying to solve every problem with one magic bullet usually ends in a half-assed solution.
-- "Old man yells at systemd"
Re:Dumb security question
by
Shiny+Metal+S.
·
· Score: 2
How feasible would it be for someone to take a computer and have
it do nothing but pattern-matching through all the source code in a typical Linux
distribution, looking specifically for problem areas like these?
Very good texts.
You can use something like
Stack Shield.
It "integrates with GCC and basically adds a little bit of code that checks
the return address of a function and makes sure it is within the correct limits,
if it isn't you can have the program exit."
My advice would be to not use C/C++ for secure
setuid programs, unless you really have to
use C/C++ and you really understand
what's going on in your program
on the very low level.
Interestingly enough, Ada's big market is the embedded market. At the same time, it's known for all the automatic checks. Hmm..
Checks should be at the *programmer's descretion*, not at the whim of a compiler or language.
Most good languages let you turn off checking when and where you need it turned off. Do you really enjoy typing the bounds checking code over and over, or do you just cut corners?
You can write safe code in any language. Likewise you can write bad code in any language. Languages are *not* the silver bullet to the problem, but you for whatever reason think they are.
Fine. You write a matrix multiplication routine in C, and I'll do it in APL. I bet I'll have a correct implementation long before you, and it'll probably be faster, to boot.
Languages aren't a silver bullet, but it's much easier to let someone else do the work, and much more reliable to boot. A compiler always puts in the bounds checking statements and always gets it right. If there's a bug, then you fix it in one place. For bounds checking, any array overflow security hole in a language with decent bounds checking is either a bug in the compiler or the programmer turning off bounds checking. That's a huge difference from the large number of bounds checking bugs in C.
If your argument was valid, games would still be implemented in assembly code. They're not so that means there's something wrong with the argument.
The problem is that good performance is just one of the many qualities you want from your system. You also want good maintainability, perfect security, the best usability, and optimal programmer productivity.
When you balance it all you will find that C no longer meets the requirements for most real world projects. It is inherently insecure, there are better languages from a point of view of programmer productivity and C code is notoriously hard to maintain due to complex syntax, preprocessor directives and other typical C issues. On top of that, in most cases the performance gain of using C is grossly overestimated and not based on any factual evidence.
--
Jilles
Re:Dumb security question
by
Kamel+Jockey
·
· Score: 2
So your second option, review/audit is a much better solution.
True, true. Never use a computer to do a human's job:)
-- In case of fire, do not use elevator. Use water!
Re:Dumb security question
by
iabervon
·
· Score: 2
The one of these I am familiar with does things with heap allocation, such that heap-allocated memory is separated by buffer zones of unallocated memory. This can be very helpful for checking bounds on accesses, but it won't catch everything.
First of all, it doesn't do anything with the stack, which is laid out by the program itself (with code generated by the compiler), and the most common buffer overruns are out of stack-allocated buffers into other parts of the same stack frame.
Similarly, it won't catch overruns of buffers in structs, where the overrun goes into adjacent fields but not out of the struct.
The essential problem is that nothing at runtime is keeping track of sizes of arrays and types of values, so incorrect usage cannot be detected. This information requires checks while running entirely non-library code, so it cannot be done by changing libraries.
Did this get released early? I got the RedHat advisory, but there is no source update at zlib.org, the CVE page at Mitre is empty and there is nothing from CERT yet.
What gives? Does anyone know where a patch is available?
--
Do you even know anything about perl? -- AC Replying to Tom Christiansen post.
Staticly linked-implication
by
joeflies
·
· Score: 3, Interesting
As the article points out, anything that uses zlib staticly can't be fixed by the new zlib patch until it's recompiled.
As I'm not a programmer, what can I grep to search stuff I've compiled from source to determine what's using staticly linked zlib?
Re:Staticly linked-implication
by
Stonehand
·
· Score: 4, Informative
You could write a script using 'nm' and 'grep' -- once you identify some functions in zlib. If they have a common prefix, search on that.
Of course, if you stripped the symbols out of the binaries, then the function names won't be there for nm to find and you're quite screwed -- basically you'd have to go grab the sources again and scan the Makefiles and perhaps the code itself for zlib references.
-- Only the dead have seen the end of war.
Re:Staticly linked-implication
by
cicadia
·
· Score: 3, Informative
You're absolutely right -- the only thing that a binary download will fix is packages using the libz.so shared library. Most software seems to link with the library statically. This is a huge problem.
I'm currently running this command against my/usr/src directory, just to get a preliminary list of packages to recompile:
Assuming you've still got your source tree intact since you compiled, this should find all makefiles which reference the zip library. If you've deleted any source directories, you will have to untar them and run configure again to build the makefiles.
--
Living better through chemicals
Re:Staticly linked-implication
by
umoto
·
· Score: 3, Informative
There are the right ways, then there is the easy, 99% effective way. The easy way is to search for very specific error message strings, which are sort of a fingerprint for most software. I compiled zlib then used "strings libz.a" to find these error messages:
too many length or distance symbols invalid literal/length code
A quick grep for one of those two strings reveals quite a number of statically linked versions of zlib in/usr/bin.
Re:Staticly linked-implication
by
wilhelm
·
· Score: 2, Informative
find / -type f -perm +0111 -print | xargs grep 'too many length or distance symbols' 2>/dev/null
Good info. It's surprising how much stuff gets a hit using this - most of the commercially-produced stuff on my hosts. Real player, Adobe acrobat reader, Netscape, most of the Loki games, the Flash Netscape plugin, among others. I have an old version of commercial ssh, which has linked itself statically as well. That's the one I'm really concerned about; sounds like time to switch to openssh, and make sure it's compiled dynamically.
Re:Staticly linked-implication
by
greenrd
·
· Score: 2
Mod this down. That's dynamic link dependencies. You want a command to find static link dependencies.
No buffer overflow!
by
lkaos
·
· Score: 3, Informative
From the zlib.org page:
The vulnerability results from a programming error that causes segments of dynamically allocated memory to be released more than once (aka. "double-freed"). Specifically, when inftrees.c:huft_build() encounters the crafted data, it returns an unexpected Z_MEM_ERROR to inftrees.c:inflate_trees_dynamic(). When a subsequent call is made to infblock.c:inflate_blocks(), the inflate_blocks function tries to free an internal data structure a second time.
Because this vulnerability interferes with the proper allocation and de-allocation of dynamic memory, it may be possible for an attacker to influence the operation of programs that include zlib. In most circumstances, this influence will be limited to denial of service or information leakage, but it is theoretically possible for an attacker to insert arbitrary code into a running program. This code would be executed with the permissions of the vulnerable program.
Duplicate deletions are not the same as buffer overflows and are no where near as easy to exploit. In fact, I have _never_ seen a duplicate deletion exploitation other than a simple DoS. Not to mention the fact that it requires a special series of calls from the calling program.
In summary, the world hasn't come to an end and Free Software is all-the-sudden as vunerable as closed source software. Put the pills down and relax:)
Re:No buffer overflow!
by
Mike+Shaver
·
· Score: 3, Informative
If the application has the "wrong" pattern of allocations and frees, it may be exploitable. One such pattern is the freeing of x, an allocation -- which gets x-(sizeof void *) -- and then the subsequent double-freeing of x.
I have _never_ seen a duplicate deletion exploitation other than a simple DoS. Not to mention the fact that it requires a special series of calls from the calling program.
Yes. A double-free is very, very hard to exploit. I don't think it has ever been done in the wild against a non-trivial program. You would not only need to know the exact algorithm of the allocator but also exact layout of the heap.
The worst the bad guy can realistically do is crash the program on a bad pointer.
The claim about this vulnerability inserting arbitrary code is simply scare-mongering.
Closed source projects that statically link
by
Anonymous Coward
·
· Score: 2, Interesting
What about closed source projects that statically link these sorts of things?
Quake 3, for example, statically links zlib in to deal with decompressing pk3 (zip) files. If the client auto-download is on, pk3 files can be downloaded from the quake server.
I don't mean to be an alarmist, but this is something that should be considered. Zlib is linked into Quake 3 on all platforms.
I was just thinking about this earlier today...
by
Mr+Z
·
· Score: 2, Interesting
This is creepy. I was wondering about possible
vulnerabilities in zlib
earlier today for a completely different
reason.
According to this
post in a different article, a recent patch to Internet Explorer disables support for gzip encoding.
Do you think, perhaps, Microsoft noticed the bug,
shut off the support (since presumably they're
just using zlib also), and just didn't say anything?
Of course, that is just paranoia. They could have plenty of other reasons.
Re:I was just thinking about this earlier today...
by
JediTrainer
·
· Score: 2
So how does that translate into "Linux is vulnerable and Windows is not?
Because free() on Windows is "less efficient" in that it does some checking to make sure it wasn't called twice with the same parameter. This is why some say 'double-frees' won't be a vulnerability on Windows.
'Course that makes it waaaay slower.
--
You can accomplish anything you set your mind to. The impossible just takes a little longer.
Re:I was just thinking about this earlier today...
by
Tony+Hoyle
·
· Score: 2
As someone who has spent many hours staring at code trying to fix double-free bugs in Windows, I can definately say that it does *not* do any checking in release mode, and in debug it misses it half the time (usually failing a couple of minutes later on a completely unrelated allocation). If course the debug checking never gets used because anyone who wants to keep their sanity uses Purify anyway.
Therefore Windows is vulnerable. Applications aren't distributed with debugging enabled anyway (it's a license violation - gotta love closed source) so bleating 'there's checking in debug mode' is not helpful.
Should I upgrade my kernel?
by
uchian
·
· Score: 2
The article says that the kernel is affected - does it statically link zlib, in which case a recompile is in order, or do I just need to upgrade the zlib package?
Or is the article lying?
Re:Should I upgrade my kernel?
by
ceswiedler
·
· Score: 4, Interesting
The only dynamic linking the kernel uses is modules, which aren't used for providing library routines like zlib. The kernel does not link.so files. The code is almost certainly cut-and-pasted into the ppp compression code somewhere.
Re:Should I upgrade my kernel?
by
Mr+Z
·
· Score: 5, Informative
One place kernel uses zlib is to compress the kernel boot image. The kernel image then gets decompressed
during bootup. So, from the standpoint of "the kernel uses zlib", the kernel is affected.
There is, however, no new vulnerability introduced
as far as I can tell. To attack the zlib-based
decompression that the kernel performs, an attacker would need to modify the compressed kernel image that is used to boot the machine.
I can think of far more fruitful ways to
compromise a machine by modifying the kernel
image than by trying to dork the zlib decompression that happens before the kernel even runs.
Another place the kernel uses ZLib is when
mounting compressed filesystems. (Compressed
RAM disks and zisofs come to mind.) In this
case, you're asking a live kernel to decompress arbitrary data. These
are only issues when mounting untrusted media.
If you made the media yourself, then your
only risk is that corrupted media might cause
a kernel oops. And if you don't have cramdisk
and zisofs compiled in, you're safe.
Other places the kernel seems to use ZLib (from a cursory scan of the source -- there may be others):
jffs2 -- Journalling Flash Filesystem version 2
ppp -- used for ppp_deflate option
In any case, the kernel is a statically linked
entity, with a minor exception for modules.
ZLib is not a module, therefore to upgrade
ZLib in the kernel, you'll need to rebuild the
kernel. And it doesn't appear to be as easy as
just upgrading ZLib and rebuilding the kernel.
The kernel has multiple modified copies of ZLib
in its source tree. I'd wait for an official
kernel patch.
Is it just me, or have there been a really huge amount of security issues with Free/Open Source software this year?
It just seems like there's a new hole (or two) every week. Let's see, we've had openssh, zlib, php, mod_ssl, cvs, cups, rsync, exim, ncurses, glibc and more, just since January. We've still got two-thirds of the year to go. Anyone want to make bets on what other projects will get hit? I think we're going to see problems with XFree86, samba, and apache.
So, my question is this: Do you think that this is simply a bad time for FS/OSS security? Are we at the threshold where there are enough eyes on the code to locate these kinds of bugs? Or is the quality of FS/OSS declining?
If the strength of Linux is closing the barn doors after the horses have ran amok, I think I'll investigate BSD, where they, you know, actively audit the code.
-- Vintage computer games and RPG books available. Email me if you're interested.
Well, there might be a lot of these buffer overflow (or double free in this case) bugs these year in FS/OSS software, but you have to keep in mind that most of these bug postings are *theoretical* security flaws. Many of these don't even have an exploit coupled with them, it's just that since people can go through the code, it's easier to see that a flaw that creates a potential security breach has been discovered.
Compare that with most of the closed-source security flaws this year, which more had to do with actual exploited vulnerabilities than with potential theoretical vulnerabilities.
I guess the difference is that in a lot of these FS/OSS projects the potential problems are announced and stomped out quicker than they can become actual exploited vulnerabilities.
A double free that creates a potential remote hole (and more likely a potential DoS) isn't good, but if we weight security flaws, I would weight that far below something like Code Red or Sircam which is being actively exploited.
Your analogy doesn't make much sense. I would say "the horses have run amok" when there are actually boxes being compromised using this hole. At the moment, this is a purely theoretical exploit. This is more like discovering the barn door was open, and closing it before any horses got out.
Your other point is a good one, though. Anyone interested in secure servers would do well to investigate OpenBSD, as they have spent huge amounts of time auditing their code.
--
"Any fool can make a rule, and any fool will mind it."
--Henry David Thoreau
Actually, I'd say this is more like finding out that the vast majority of barn doors can be opened by knocking in a certain pattern, and knowing for a damn fact that most farmers won't bother to install the new latch that's being given away for free.
My point mainly is that while having armies of college students coding is wonderful in some respects, it's horrible in other respects.
-- Vintage computer games and RPG books available. Email me if you're interested.
I agree that discovering that the barn door could be opened before it was installed is the best solution, however just in case something is found, you have to have a half-decent backup plan.
This is something that I believe Windows XP got right - by forcing users to download the latest patches, it means that the clueless are no longer vulnerable, and those who know enough to turn the updates off are either keeping up with the patches themselves, or basically have nobody to blame when Code Red III comes along...
"...most of these bug postings are *theoretical* security flaws."
L0pht Heavy Industries: "Making the theoretical practical since 1992."
The fact is, a theoretical flaw is still a flaw, and it's still relevant to my original question.
"Many of these don't even have an exploit coupled with them..."
...yet.
"I guess the difference is that in a lot of these FS/OSS projects the potential problems are announced and stomped out quicker than they can become actual exploited vulnerabilities."
This is something that's been bugging me as well. It seems that more security bugs are kept quiet until a fix is prepared. Personally, I'd much rather know ASAP, so I can at least disable or filter the vulnerable service. I think that as soon as a vuln. is discovered & discussed on any public list, the more likely it will be that there is an exploit available. In some cases (WU-FTPd globbing bug comes to mind), the vuln. was known about for some time before the fix was available. In this case, there was even an exploit available. The bug was discovered in July, a security advisory was being drafted as early as September, and the fix didn't get released until December.
Its because buffer overflows are a hot topic now. Microsoft made them famous due to the exploits. Now everyone is quick to point them out and post them on their websites. I'd almost bet buffer overflow news in your favorite OS would get just as many hits as your favorite teen popstar naked. God knows I've done more searches this year for Red Hat and Windows bug errata than I have for Britney Spears' boobs.
As for the quality of free and open source software, well, I've never understood why people think it is any better than commercial software. I've been a professional programmer for 10 years and I've seen whack commercial code, whack open source code, and I'm pretty sure I've written some whack code myself. The license doesn't have much to do with it except for having NDA's keeping me from discussing some commercial code. Having open source visible on the bug watch list doesn't hurt much because fixes are usually available. Its when people don't pay attention to the fixes that the problem gets out of hand. Remember, the fix to the exploit that Code Red used was out a few weeks before Code Red. Now if we see this zlib bug take down a big chunk of the Linux communitiy in a few weeks then it will be a bad thing because we didn't pay attention.
--
'Same speed C but faster'
zlib rarely used in MacOS. MacOS safe.
by
Anonymous Coward
·
· Score: 2, Interesting
Thankfully the 9000 lines of regularly coped and pasted source commonly known as zLib does not infest the MacOS universe or mac servers at least.
The MacOS running WebStar as a server has never been exploited.
In fact in the entire securityfocus (bugtraq) database history there has never been a Mac exploited over the internet remotely.
That is why the US Army gave up on MS IIS and got a Mac with WebStar.
I am not talking about BSD derived MacOS X (which already had a couple of exploits) I am talking about Mac OS 9 and earlier.
Why is is hack proof? These reasons:
1> No command shell. No shell means no way to hook or intercept the flow of control with many various shell oriented tricks found in Unix or NT
2> No Root user. All mac developers know their code is always running at root. Nothing is higher (except undocumented microkernel stufff where you pass Gary Davidians birthday into certain registers and make a special call). By always being root their is no false sense of security.
3> Pascal strings. ANSI C Strings are the number one way people exploit Linux and Wintel boxes. The mac avoids C strings historically in most of all of its OS. In fact even its roms originally used Pascal strings. As you know pascal strings are faster than C (because they have the length delimiter in the front and do not have to endlessly hunt for NULL), but the side effect is less buffer exploits.
4> Stack return address positioned in safer location than intel. Buffer exploits take advantage of loser programmers lack of string length checking and clobber the return address to run thier exploit code instead. The Mac places return address infornt of where the buffer would overrun. Much safer.
5 : Macs running Webstar have ability to only run CGI placed in correct lodirectoy cation and correctly file typed.
6> Macs never run code ever merely based on how a file is named. ",exe" suffixes mean nothing. For example the file type is 4 characters of user-invisible attributes, along wiht many other invisible attributes, but these 4 bytes cannot be set by most tool oriented utilities that work with data files. For ecxample file copy utilities preserve launchable file-types, but JPEG MPEG HTML TXT etc oriented tools are physically incapable of creating an executable file. the file type is not set to executable for hte hackers needs. In fact its even more secure than that. A mac cannot run a program unless it has TWO files. The second file is an invisible file associated with the data fork file and is called a resource fork. EVERY mac program has a resource fork file containing launch information. It needs to be present. Typically JPEG, HTML, MPEG, TXT, ZIP, C, etc are merely data files and lack resource fork files, and even if the y had them they would lack launch information. but the best part is that mac web programs and server tools do not create files with resource forks usually.. TOTAL security.
7> There are less macs, though there are huge cash prizes for craking into a MacOS based WebStar server. Less macs means less hacvker interest, butthere are millions of macs sold, and some of the most skilled programmers are well versed in systems level mac engineering and know of the cash prizes so its a moot point, but perhaps macs are never kracked because there appear to be less of them. (many macs pretend they are unix and give false headers to requests to keep up the illusion, ftp http, finger, etc).
8> MacOS source not available traditionally, except within apple, similar to Microsoft source availability to its summer interns and such, source is rare to MacOS. This makes it hard to look for programming mistakes, but I feel the restricted source access is not the main reasons the MacOS has never been remotely broken into and exploited.
Sure a fool can install freeware and shareware server tools and unsecure 3rd party addon tools for e-commerce, but a mac (MacOS 9) running WebStar is the most secure web server possible and webstar offers many services as is.
I think its quite amusing that there are over 200 or 300 known vulenerabilities in RedHat over the years and not one MacOS remote exploit hack. And Now ith zLib, even more holes can be found in Linux.
Re:zlib rarely used in MacOS. MacOS safe.
by
Account+10
·
· Score: 2, Insightful
Wrong...
free(p);
free(p);
what happens if there is a thread switch between the two calls to free? Another thread can call malloc and receive the same value 'p' back.
When we switch back to this thread, it will free memory another thread still thinks it owns.
Calling free() twice on the same pointer is never safe.
Re:zlib rarely used in MacOS. MacOS safe.
by
yeOldeSkeptic
·
· Score: 2, Interesting
I hate to send rain on your parade but...
No command shell. No shell means no way to hook or intercept...
A command shell is just a convenient way to go around a UNIX system
after you've logged in. It has nothing to do with the question of
a box being easier to crack. Once you've been compromised, you've
been compromised --- whether you have a shell or not.
All mac developers know their code is always running at
root. Nothing is higher...
By always being root their is no false sense of security.
Tell that to the hapless windows user. Everyone is root there,
that didn't make windows more secure. Being root all the time
only means that when you have executed an email worm, it is trivial
for the worm to do anything it wants. The only reason Macs were'nt affected
by the ILOVEYOU virus is because Macs are not running visual basic.
Pascal strings...
are faster than C (because they have the length
delimiter in the front...
Which means I have only to change that
single number and I'll have what amounts to a buffer overran. Especially
if...
...
The Mac places return address infront of where the buffer would overrun.
Much safer.
Placing the return address in front of a buffer rather than at
the end is safer but does not guarantee that the machine won't be
compromised. Why?
Assume there is a function a() which calls b()
sometime after being invoked. In the Mac architecture, the return
address for a() is placed between buffer allocations for a()
and buffer allocations for b(). If the buffer allocated by a()
is globally accessible, then it is possible for some routine
c() to access that buffer, overrun the return address,
and have arbitrary code executed when b() returns. Granted, this
is more difficult to do than is the case with the intel architecture
but it is entirely possible. Having a different way of storing
return addresses is not a substitute for careful, paranoid programming.
Macs never run code ever merely based on how a file is named....
And so do Unix. The Mac style is even more readily compromised if
as you say, "A mac cannot run a program unless it has TWO files."
One of which is invisible. Imagine that!
You have a file that
cannot be seen by the ordinary user or by the standard file tools
provided by default. What would happen if someone (could
be you running a trojanned program) changes those so called ``hidden
attributes?'' (Discussion left as an exercise for the student.)
There are less macs,...
This is the real reason there are no Mac related compromises
on Bugtraq or anywhere. There are so few of them it just isn't
worth it for the script kids. But what kind of advertisement for
security is that? Mac Proven Safer because Unpopular and
Slow-Selling!
Re:Programming languages: fool me once ...
by
CDWert
·
· Score: 2
You have a point. Maybe this is MS intention of C# to avoid their own problems with just this issue. (I am of course joking we all know world domination throught IT enslavement is the real goal)
But a point you may be missing is MANY of the languages are built on C and as a result in effect inherently unsafe as well, unless they are self hosting.
-- Sig went tro...aahemmm.....fishing........
Easy Workaround!
by
dtrombley
·
· Score: 5, Interesting
Well, it won't prevent the DoS aspect - but, from the malloc manpage:
Recent versions of Linux libc (later than 5.4.23) and GNU libc (2.x) include a malloc implementation which is tunable via environment variables. When MALLOC_CHECK_ is set, a special (less efficient) implementation is used which is designed to be tolerant against simple errors, such as double calls of free() with the same argument, or overruns of a single byte (off-by-one bugs). Not all such errors can be proteced against, however, and memory leaks can result. If MALLOC_CHECK_ is set to 0, any detected heap corruption is silently ignored; if set to 1, a diagnostic is printed on stderr; if set to 2, abort() is called immediately. This can be useful because otherwise a crash may happen much later, and the true cause for the problem is then very hard to track down.
Seems worth it while all pour through the symbol tables of our static binaries (and recompile the stripped ones. =( )
On another note, I've always regarded security bulletins as a one-way process... For example, I couldn't find a way to tell RedHat they'd omitted this (seemingly important?) reminder. Any thoughts about this? (admittedly i didn't look very hard for very long)
How do you set this variable system wide so, say, server processes like Apache which may use zlib get MALLOC_CHECK_ 2. Is there a way to globally set an env var with modifying/etc/rc.d/init.d/* ?
Sure, modify/etc/rc.d/rc or/etc/rc.d/init.d/functions. If you look in the latter file on Red Hat, you will see that it sets a number of environment variables.
Erm, I hate to ruin your little world and all, but FreeBSD uses zlib, too.
--
-- I Hit the Karma Cap, and All I Got Was This Lousy.sig.
Wasnt it buq fixing month ?
by
Quazion
·
· Score: 2, Interesting
And it seems they arent too a shame to tell they made mistakes;)
But to answer your last question, its seems its only getting better with finding all these bugs and all.
One more bug OpenSSH is affected by...
by
Anonymous Coward
·
· Score: 3, Informative
OpenSSh uses zlib - if you happen to compile OpenSSH statically with zlib (I think thats the default), one more upgrade cycle after the latest OpenSSH 3.0.2p1 bug...:(
Re:The article says this is only affecting Linux
by
Ded+Bob
·
· Score: 3, Interesting
I think it does hit FreeBSD. FreeBSD uses zlib v1.1.3. v1.1.4 has the fix (http://www.gzip.org/zlib/). No security announcement has arrived in my mailbox, yet I expect it soon.
It's not a problem in zlib per se
by
Starship+Trooper
·
· Score: 5, Insightful
This bug causes zlib to free() a malloc'ed block of memory more than once. free() on most other OS's (including Windows, FreeBSD and OpenBSD) is smart enough to check for this and will print a warning instead of destroying the heap; glibc's malloc (and by extension, Linux's) does not and will gleefully make a mess out of the whole memory space. This can cause all sorts of buggery when the next malloc() occurs, including what amounts to a buffer overflow exploit.
So, you should download the patched zlib, but you should also email the glibc maintainers and demand that they implement a sane, error-checking malloc()/free() system. Linux's current allocation model is a disaster waiting to happen.
-- Loneliness is a power that we possess to give or take away forever
Re:It's not a problem in zlib per se
by
slamb
·
· Score: 5, Informative
This bug causes zlib to free() a malloc'ed block of memory more than once. free() on most other OS's (including Windows, FreeBSD and OpenBSD) is smart enough to check for this and will print a warning instead of destroying the heap; glibc's malloc (and by extension, Linux's) does not and will gleefully make a mess out of the whole memory space. This can cause all sorts of buggery when the next malloc() occurs, including what amounts to a buffer overflow exploit.
If you want this behavior, you can get it easily on Linux/glibc. From the malloc(3) manual page:
Recent versions of Linux libc (later than 5.4.23) and GNU
libc (2.x) include a malloc implementation which is tunable via environment variables. When MALLOC_CHECK_ is
set, a special (less efficient) implementation is used
which is designed to be tolerant against simple errors,
such as double calls of free() with the same argument, or
overruns of a single byte (off-by-one bugs). Not all such
errors can be proteced against, however, and memory leaks
can result. If MALLOC_CHECK_ is set to 0, any detected
heap corruption is silently ignored; if set to 1, a diagnostic is printed on stderr; if set to 2, abort() is
called immediately. This can be useful because otherwise
a crash may happen much later, and the true cause for the
problem is then very hard to track down.
Re:It's not a problem in zlib per se
by
dtrombley
·
· Score: 2, Interesting
This is not entirely accurate.
See my earlier post: about a workaround.
Mind you, the manpage cited/is/ annoyingly vague about the behavior of this facility, but you should keep in mind there is a performance/feature tradeoff, and your criticism assumes we should strive for robustness over performance.
Re:It's not a problem in zlib per se
by
Anonymous Coward
·
· Score: 4, Insightful
so what you are saying is that slashdot has been wrong in the past to criticise microsoft for seeking performance ahead of robustness. glad we've cleared things up.
mjl
Re:It's not a problem in zlib per se
by
Ed+Avis
·
· Score: 3, Informative
AFAIK: The kernel doesn't use the glibc C library. It has its own memory management code which presumably the kernel zlib code uses. This memory manager may or may not guard against free()ing the same area twice.
But what is the use of zlib in the kernel anyway? Just to uncompress the vmlinuz image before the kernel starts? If so it's not much of a vulnerability, if you can corrupt the vmlinuz file then you can control the whole system anyway.
-- --
Ed Avis
ed@membled.com
Re:The article says this is only affecting Linux
by
somethingwicked
·
· Score: 2
Some glory hound at Redhat found it.I doubt he fired up a windows machine and tested it before he realized he could get his name in the news.
I bet you are one of the ppl that instantly criticizes when you hear that M$ (or insert fav evil corp) knew about a vulnerability and kept it quiet for a month.
Damned if ya do...
--
---"What did I say that sounded like 'Tell me about your day?'"---
Sounds like that disaster you speak of did just happen. Well, maybe not quite a disaster, but anytime I have to upgrade 20+ packages for one bug, that's bad.
--
This sig has been temporarily disconnected or is no longer in service
Not a surprise...
by
Joseph+Vigneau
·
· Score: 2, Insightful
Is it just me, or have there been a really huge amount of security issues with Free/Open Source software this year?
Yes; perhaps this is due to the fact that FS/OSS is used by more developers/users. More eyeballs and more code to exercise libraries mean more bugs are discovered. As mentioned, this bug is (relatively) benign, and has already been fixed in the source. So I wouldn't necessarily say that FS/OSS is getting "more buggy", any more than commercial software, whose bugs don't leave the company if users don't discover them first.
Re:Version 1.1.4 fixes the problem
by
BlowCat
·
· Score: 2
No, it's not the site, it's the poster who is suffering from the/. effect (actually, syndrome). The/. syndrome is: post as fast as possible and get tons of karma from moderators who don't check the links.
This is why you clear pointers after freeing them
by
coyote-san
·
· Score: 5, Informative
This is why you ALWAYS set a pointer to NULL after freeing it, even if it's "totally unnecessary" because you're about to free the structure holding the pointer.
This doesn't prevent attempts to free the previously freed pointer, but that will generally do a lot less damage than freeing a real malloc'd address. And during development it's trivial to add an assertion checking for a NULL pointer before any free().
-- For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
...shame on the distribution publishers.
by
yerricde
·
· Score: 2
Yet why in the name of all that is good do they not realize that C is an inherently unsafe language. There are some really good free alternatives to C, so why the heck are those numbskulls not using them?
Because most distributions of GNU/Linux operating systems don't install any compiled languages but C and C++. (There is no language called "C/C++".)
Because popular libraries have C bindings.
Because compilers can optimize C code for machines with limited resources. (Java technology is a memory hog partly because of the 16-byte overhead of java.lang.Object.)
Because people think in "step 1, step 2, step 3" of an algorithm, rther thn in functionl style (partially ruling out CL, ML, and Haskell).
Take your choice: Eiffel, Ada, Modula-3
Which of these languages is in the default devel install in all the major distros and can link to libraries' C bindings?
This bug was not reported on Bugtraq yesterday. In fact, it's not been mentioned on Bugtraq at all yet.
Then there's still a problem in glibc malloc()
by
Starship+Trooper
·
· Score: 5, Insightful
*BSD's malloc manages to simultaneously provide high performance while also providing robust (and highly configurable) error checking. glibc's MALLOC_CHECK_ variable does far too much and isn't nearly as fine-grained as BSD's options. Read the "TUNING" section of FreeBSD's malloc(3) manpage. It puts Linux to shame as far as clarity, usefulness, and convenience goes. You only turn on the error checks you need, instead of a few general and poorly-implemented checks in glibc's malloc.
Why Linux can't follow in the supposedly-inferior BSD's footsteps is beyond me.
-- Loneliness is a power that we possess to give or take away forever
Re:Then there's still a problem in glibc malloc()
by
Anonymous Coward
·
· Score: 2, Informative
Don't be ridiculous. Get your facts straight. Every good UNIX programmer knows that glibc's malloc is based on Doug Lea's excellent malloc library which one of the fastest and most space efficient single-threaded memory allocators available - much much better than the BSD version. I even recall a BSD mailing list thread not too long ago about wanting to incorporate the Lea-based allocator to replace the inefficient powers-of-two based allocator used in BSD.
The packages affected by the double-free() libz bug can be devided into
two categories:
1) packages that link dynamically against the system-provided
compression library. These packages get fixed automatically with
the update of the libz package as described in SuSE-SA:2002:010.
Please note that the processes will continue to use the old
version of the libz.so shared library if the have not been
restarted after the libz package upgrade.
2) packages that contain the compression library in their own
source distribution. These packages need an individual bugfix.
We have prepared update packages for this software that can be
downloaded from the locations as shown below.
The following is a list of the packages in category 2):
gpg
rsync
cvs
rrdtool
freeamp
netscape
vnc
kernel
Not that quick... this was a coordinated release of the bug Owen Taylor at Red Hat found by investigating a bug against Gnome. This wasn't found yesterday, vendors have had time to create and test packages.
Its mostly because a certain large vendors publicity machine keeps pushing any bug report that impacts open source in the slightest as a big thing and feeding it to the press.
Dirty game really, but thata how they play it.
This is why news stories keep starting with Linux blah and then turning into "everyone blah"
And inversely, any bug report for a certain large vendor starts out being an "internet flaw" or an "web browser/email bug" and eventually is clarified to affect only a specific vendor's product.
In this case, it's just a lame attempt of Slashdot to be "provocative". However, there is some truth in saying that it's a Linux (actually, GNU/Linux and Linux kernel) problem.
As other posters noticed, GNU libc defaults to an unsafe but faster free() implementation that can damage the heap if called more than once on the same pointer. Other operating systems are said to default to a safer malloc() implementation.
The question is, if, and to which extent, potential extra security justifies real trade-offs in speed.
Using shared libraries is not free of trade-offs. Position independent code (PIC) used in them is slower on many architectures, including x86. However, shared libraries are preferred because, should anything like this bug in zlib be found, the only package to replace will be the faulty library (and the "offenders" linking to it statically, like CVS and rsync).
But the measure that could have prevented this bug from being an issue on GNU/Linux has not been taken on the same grounds of speed! Yet I think that a lot of programs suffer (in terms of speed) more from slower PIC code than from safer malloc(). No I'm not suggesting going back to static libraries. Rather, we should acknowledge that there is a price tag attached to the peace of mind.
Linux kernel developers should have examined the zlib code for compatibility with Linux kernel-space memory management.
Not much, and this is already being done. The real problem is with "free(ptr); free(ptr);"
Re:That's better
by
cpeterso
·
· Score: 3, Insightful
If they ripped them off as you say they would not be able to licence them as GPL now could they?
sure they could. The BSD license lets anyone do whatever they want, including relicense the code as GPL. There is already BSD code in the Linux kernel.
Re:This is why you clear pointers after freeing th
by
Stonehand
·
· Score: 2
The assertion being tripped would, however, be a useful diagnostic if you prefer to know when something is being freed twice. For instance, if there exist two separate pointers to an object, which itself contains a pointer that gets set to NULL when freed, a well-placed assertion would tell you if you've got a logical error -- trying to deallocate a dangling pointer, basically.
Simply clearing it to NULL means that such won't be found, which may hide related errors. Letting it be freed twice would simply be sloppy and asking for trouble.
-- Only the dead have seen the end of war.
The bright side of the bug
by
seldolivaw
·
· Score: 2
While it's annoying to discover a buffer-overflow problem (or whatever; I haven't examined the report closely) in Linux and other OSS, if you ever wanted confirmation that Linux is being taken seriously by the public at large, it's that c|net thought a Linux bug worthy of reporting. Has that ever happened before?
Re:This is why you clear pointers after freeing th
by
greed
·
· Score: 3, Informative
Calling free() on a NULL pointer is a no-op. No check or assertion is needed.
The assertion lets you catch the logic error that led to the second free during debugging. Presumably, your code path wasn't expecting the pointer to already be free at that point; otherwise, you would have designed it to handle that case already.
Then, in production code, if you do take that path, you'll get the harmless no-op free(0). (You do build production with -DNDEBUG, right?)
Re:So much for "many eyes"....
by
jgerman
·
· Score: 2
Don't mistake tasteful discretion for tyrannical repression, it'll only make you paranoid.
Did you come up with that one? Well put. I may have to make that my sig, I feel the same way, wish I had thought up that one.;)
-- I'm the big fish in the big pond bitch.
Count based on advisory at SecurityFocus
by
sterno
·
· Score: 2
My count of 20 packages is based on the warning redhat distributed. They recommend upgrading some 22 packages on a Redhat 7.2 system. This includes several packages for the kernel, zlib itself, and a number of other applications that are statically linked such as cvs, dump, etc.
The scary thing is, I may have installed other apps that have zlib statically compiled that I don't even know about because they aren't part of the default vendor distribution.
--
This sig has been temporarily disconnected or is no longer in service
Re:Count based on advisory at SecurityFocus
by
MSG
·
· Score: 2
They recommend upgrading some 22 packages on a Redhat 7.2 system.
Most of those packages are related to gcc3 and vnc, which you probably don't have installed. Leave off those two, and you have about 6 or 7 updates left, including the zlib package.
This includes several packages for the kernel...
Actually, kernel 2.4 is absent from the list of updates.
Linux: 1. Flaw Found 2. Flaw fixed for current and previous distributions.
Windows 1. Flaw found 2. Flaw claimed to be feature 3. Large Corporation bothered by flaw 4. Flaw patch developement begins. 5. Beta release of flaw pack 6. Beta 2 release of flaw pack 7. RC1 of flaw pack 8. Flaw pack released for new OS products 9. 1 month later flaw pack released for most widely used OS version.
On Linux : add this at the beginning of your/etc/rc file and in your shell init scripts:
export MALLOC_CHECK_=2
(don't forget the extra underscore at the end).
On BSD systems:
ln -s ZH/etc/malloc.conf
It will protect both your statically and dynamically linked apps. It adds a little performance penalty, but it's really not noticeable.
-- {{.sig}}
Re:The article says this is only affecting Linux
by
Ded+Bob
·
· Score: 2
When I left my comment, it wasn't there.:)
I guess it is only partially immune: http://www.kb.cert.org/vuls/id/368819. Reading the security list I gather that it is only a problem with regards to running Linux apps. Time to give FreeBSD's free() a hug.:)
Re:That's better
by
Geekboy(Wizard)
·
· Score: 2, Insightful
The TCP stack for almost all OS's was {stolen|borrowed|based on} the TCP stack in BSD 4.x (IIRC). I remember once, a few years ago, a system engineer did a special sequence on a Windows 98 computer, and got the BSD copyright to show up.
VM in Linux is a mess. 2 (very) different VM systems, that cause quite a few utilities to be re-writtian. All of the BSD's have one each, and they optimize their VM quite well. FreeBSD has a very robust one, that is a bit slower than Linux's, but seems to be more stable.
OpenBSD just got statefull firewall with the latest version (3.0) Prior to that, they were using Darren Reed's IPF, but due to a licensing fiasco (and petty name calling), IPF was yanked, and PF was created. I use PF in my firewall at home, and I am quite happy. I can't wait until 3.1 (not willing to run -current) to see how much more robust it can get. =)
Re:This is why you clear pointers after freeing th
by
istartedi
·
· Score: 2
Problem: What if you have a structure that *optionally* allocates memory, and your cleanup code for that structure just frees all the pointers?
I have never bothered to check free because my rule is: for every init of a structure, make sure you call the cleanup.
This has worked for hundreds of kLOC of C I've written. Also, debugging heaps are nice.:)
-- For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
Because when closed source software (not limited to just MS) has a security bug it was found because somebody managed to exploit it. When you find bugs in open source software you don't have to find them with an exploit, you can find them with your eyes.
Remote upgrades : be careful
by
chrysalis
·
· Score: 3, Insightful
If you have to remotely upgrade the zlib library, be *very careful*.
Because SSH/OpenSSH depend on zlib, if you replace your current libz.so file with another version whoose API has a bit changed, your SSH server won't work any more.
So if you don't have access to the console, open a classical 'telnet' port for a few minutes, just during the upgrade. Once you've checked that SSH is still ok, you can remove the telnet daemon.
If SSH doesn't work any more after the zlib upgrade, recompile SSH.
-- {{.sig}}
Re:Remote upgrades : be careful
by
Electrum
·
· Score: 4, Informative
So if you don't have access to the console, open a classical 'telnet' port for a few minutes, just during the upgrade. Once you've checked that SSH is still ok, you can remove the telnet daemon.
Since the SSH server forks after you've connected, you can safely stop the server while connected via SSH. You never need to use telnet. Just make sure that you can still connect before disconnecting from the original SSH connection.
If you read the redhat advisory you will see. And we are talking RedHat here Dude.
* Relevant releases/architectures: Red Hat Linux 6.2 - alpha, i386, i586, i686, sparc Red Hat Linux 7.0 - alpha, i386, i586, i686 Red Hat Linux 7.1 - alpha, i386, i586, i686, ia64 Red Hat Linux 7.2 - i386, i586, i686, ia64 * Followed by the direct link to the updates for all the above distributions dude !
If any of you are running late model, production Red Hat servers for any purpose, I expect you probably heard about this way before today.
Users of Red Hat Linux 7.1, or 7.2 should update to the currently released kernel errata RHSA-2002-028 (2.4.9-31) which already contains this fix.
Kernel 2.4.9-31 was released by Red Hat well over a week ago. There were patches released for earlier distros as well. If you're not using the up2date program to perform system updates then you should at least be using it to check when packages become available.
So, yes, there is a problem with zlib. But if you have good administrative practices you have either taken care of this already, or have a formulated plan to deal with it. Either way, this should not be news to a decent Red Hat administrator.
-- I'm against picketing, but I don't know how to show it.
Re:Here's the redhat rpms
by
scorcherer
·
· Score: 2
For other arch's, substitute 'ia64' or 'SRPMS' for 'i386'
Shouldn't that be 'src' instead of 'SRPMS'?
--
--
The Cap is nigh. Time to get a fresh new account.
Because SSH/OpenSSH depend on zlib, if you replace your current libz.so file with another version whoose API has a bit changed, your SSH server won't work any more.
Existing SSH connections, however, will continue working. It's just the opening of new connections by sshd that will break.
So just keep an SSH session open until your sure the upgrade went OK. No need to hand out your passwords over telnet.
--
-- Kuro5hin.org: where the good times never end.;-)
on most other OS's (including Windows, FreeBSD and OpenBSD) is smart enough to check for this and will print a warning instead of destroying the heap
Windows, Smart? What bullshit, unless things have changed since 98. I've written programs that did the double free thing and never saw an error message other than my or some other program freezing up. With all the "uber-patches" and what not M$ needs monthly, I just don't think that is so.
The only insecure thing I do with my home network is use a windows machine at work to log into it. Apt-get update and upgrade, all fixed in ten minutes before I go home. I'm going to have to call the folks at Red Hat to figure out up2date when I get home, sigh. The M$ box that I have to use for cameras and a scanner? It's blind to the network and usually runs Red Hat. IE? Eye-EEEEEeeee!
If you compile in debug mode with Visual C++, it does all kinds of checks on malloc/delete calls.
Oh, I thought that the original troll was talking about Windows itself. Silly me.
This troll, however must also be false. If it were true, Outlook, IE and other cruft from M$ would not continue to be plauged with overflows, memory leaks and what not. The results are more powerful than promises.
Don't forget that big string of linux box hijackings that happened because of all said holes! Oh, wait there were none.
Sorry, I must have gotten confused with all those viruses like code red, nimida, sircam, and countless minor expoits for M$ OS. Ha Ha!
--
Friends don't help friends install M$ junk.
Pointer aliasing...
by
Tom7
·
· Score: 3, Insightful
I dunno, most double frees come from freeing DIFFERENT copies of a pointer. Setting one to NULL won't help in this case...
(A much better solution is to use a garbage collector.;))
Internet Explorer too!
by
Myria
·
· Score: 2, Interesting
In a recent reverse engineering session, I noticed that Internet Explorer uses zlib!
myria
-- "Screw Sun, cross-platform will never work. Let's move on and steal the Java language." - Visual J++ Product Manager
Re:That's better
by
red5
·
· Score: 2, Informative
Cool but it still bugs me when people say Linux just stole it's TCP/IP, VM etc from BSD.
They never offer any evidance of it and all it serves to do is belittle the efferts of the linux community.
I understand that these people don't represent the BSD community. It's still anoying though.
I'm verry thankfull for what Linux/GNU has given me for free. how else would a kid like me get access to UNIX a C compiler etc.
And if the BSD community supplied any of that they diserve there props too. But the guy didn't have to be a dick about it is all I'm trying to say .
-- I know I'm going to hell, I'm just trying to get good seats.
Troll? Bah, more like a zealous moderator. Like it or not, I stand by my statement: the irony is funny. If you can't see that, pull your head out of your kernel and get a life.
If the strength of Linux is closing the barn doors after the horses have ran amok, I think I'll investigate BSD, where they, you know, actively audit the code.
Perhapse you'd like to catch up on recent events with OpenSSH? Yes. The one from OpenBSD.
Yes, if security is your main concern, one should consider OpenBSD. And their creating of OpenSSH is a great service towards the entire open source (heck - IT / infosec) community. But lets not use it in a lame attempt at a flame war.
Would be impossible in garbage-collected language!
by
Tom7
·
· Score: 5, Interesting
Like most recent security holes in linux software, this one would be unexploitable in a modern safe language. (In fact it would be *impossible* to make this error in a garbage-collected language!)
The typical response I hear to this kind of comment is that "high level languages are inefficient". (I don't belive this is true, but most other people here do.) But whatever, let's pretend they are.
Now, what kind of crazy world do we live in where we value performance more than correctness (security)?? We are seeing more and more security holes as we try to write bigger and bigger packages in C. Why do we accept this? Who here really cares more about the performance of zlib than the time it takes for them to patch all of their statically-linked software, and their risk of being rooted until they do? I sure don't.
Forget about all this "coding practices" stuff. It simply takes too much effort to produce bug-free code in C. The OpenBSD people, kings of code review, just had an exploitable bug in sshd! While we need to use C for some tasks (ie, most parts of the kernel), I think we are seriously unpowered to do this for most applications (as evidenced by the high number of simple errors made, and sometimes caught).
If we simply wrote our software in high level languages, we would automatically rule out the largest classes of security holes, which would give us a lot more time to work on more important things, like high level architecture review and optimizations. I think we'd end up with a better system. So what's keeping us?
Open Source does not mean it's actually reviewed!
by
Tom7
·
· Score: 2
Unfortunately, most code isn't reviewed (or if it is, it's not reviewed carefully). I think it's just a myth that openness implies more review. (One might even make the argument that openness causes laziness!)
In fact, the very first piece of linux code I looked at carefully (the MD5_crypt code in PAM) had some very obvious mistakes in it. Anyone actually auditing it should have noticed it. And this is a highly security-critical piece of code!
I'm not saying that open source doesn't have its benefits (it certainly does), but simply making something open doesn't make the code better. People have to actually review it, and they seldom do.
Re:Would be impossible in garbage-collected langua
by
lkaos
·
· Score: 2
Ok, explain to me how one is going to implement a Garbage Collector in the kernel?
If libz was written in anything other than C, it could not be used in nearly as many applications as it is currently.
--
int func(int a);
func((b += 3, b));
Re:Would be impossible in garbage-collected langua
by
Tom7
·
· Score: 2
Another (?) AC flames,
> Yeah, and Java VMs don't also have coding errors. > You must be the only Java user in the world not > have their JVM app crash on them for no reason. > The Hotspot JVM is written in C++ and is also > subject to these same types of issues.
The fact that you immediately think I must be talking about Java shows that you need to do some more learning. There are many high-level, safe languages! (And Java is about 30 years behind the best of them...) For instance, check out O'Caml for a natively-compiled, yet safe language.
Either way though, writing more code in a safe language reduces the size of your trusted code base, and this makes it easier to audit your code.
It's actually written in the specs.
by
ncoder
·
· Score: 2, Interesting
From the C/C++ books i've read, I was told that free/delete operations as written in the ANSI spec _specifically allow_ any behavior, including a full systems crash, in the case of a erronous use of free/delete. All this for performance reasons. They assume the programmer knows how to handle his stack.
In retrospect, this seems like negligence. But it only reflects the concenrns and the focus of C/C++ at the time : Speed.
XFree86 4.2.0??
by
gweihir
·
· Score: 3, Insightful
The latest XFree comes with a copy of zlib 1.0.8.
Does anybody know where this is used and whether I should do a rebuild with the current 1.1.4 version?
In addition to gs, this seems to be the only software package that contains zlib in it. I found it because there is a/usr/X11R6/lib/libz.a on my Linux system.
-- Most ACs are not even worth the keystrokes to insult them. Be generically insulted and ignored otherwise.
Re:This is why you clear pointers after freeing th
by
coyote-san
·
· Score: 2
Yeah, so what? I know plenty of other languages, but if a client has a few million LOC in C the only thing they will do when I suggest changing to a "safe" language is thank me for my services and show me the door.
In contrast, I can usually get by with baby steps. Turning on compiler warnings and code hygiene to start, then assertions, etc.
-- For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
OOkay, I'm showing my age again....
by
coyote-san
·
· Score: 2
Sorry for showing my age. I learned C in '83 or so, and back then free() did not do special checks for NULL pointers. At least, not in some of the cheap-ass libraries we used!
I knew that C++ delete was NULL-safe, but I had forgotten that the C free() is also supposed to be NULL-safe now.
-- For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
Re:This is why you clear pointers after freeing th
by
coyote-san
·
· Score: 2
That reminds me of a horror story I once heard. Fortunately it wasn't me....
This poor guy spent hours inspecting a parse tree after a core dump. He couldn't find anything wrong. Then, finally, he realized that he was looking at the *last* parse tree - the one that the system handled without a problem. The parse tree that caused the system to crash was a lot smaller and had an immediately obvious problem, but the address of the root node was just a little bit different from the address of the root node of the old parse tree. Something easily overlooked.
Starting that day this guy was religious about setting pointers to NULL, status flags to DELETED, etc., whenever he released an object.
-- For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
As long as you're not using a crap distro that statically links zlib all over the place, the fix for this is trivial. Install a patched zlib package and you should be pretty safe. The only instances of static zlib linking in Debian are:
So upgrade these too if you happen to use them. ppp would be the most critical of those for most people.
Traceroute hack not a double free
by
Huusker
·
· Score: 3, Interesting
I think the traceroute hack is an example of freeing garbage, not a double-free(). The garbage being freed happens to be part of the command line, which is how the hacker injected his/bin/sh. The traceroute exploit description did not give full details, but I don't see how it could be possible to use modify ((int*)p)-1 using the zlib vulnerability. Remember that all mallocs are sizeof(8) aligned and have a minimum size of 16 (with overhead and internal fragmentation).
Re:The article says this is only affecting Linux
by
Lazaru5
·
· Score: 2
It is fully immune. Free|Net|OpenBSD are listed because they do use zlib and the same (already patched in Jan and Feb) bug exists. However, it's not exploitable because double-frees don't cause apps to segfault. THAT code was checked in (In FreeBSD) over 6 years ago.
--
--
My comments and opinions completely reflect those of anyone and anything I am remotely associated with.
I'll be sure to think of how horrible and inferior Microsoft is while I'm rebuilding my kernal and half my apps over the next few days. (Not to mention the fact that I still have OpenSSH on remote machines that need patching). Meanwhile, my wife hits Windows update every day and gets fresh binary patches with little effort.
Re:That's better
by
red5
·
· Score: 2, Informative
No, one they stole, one they wrote themselves.
Linux didn't steal shit otherwise someone would post some code comparissions by now. It's not exacly hard to get the code (There both free for download).
So my message to you trolls is put up or shut up.
I want to see proof showing that the code used in the linux kernel was copyed from BSD.
Until then go fuck you self.
-- I know I'm going to hell, I'm just trying to get good seats.
Re:Would be impossible in garbage-collected langua
by
Tom7
·
· Score: 2
An AC flames,
> Show me one such high level "safe" language with > the performance and low-memory characteristics of > C. Lisp? O'Caml? Scheme? Snobol? Please.
I'd say both SML and O'Caml fit that, yes. Also Popcorn and Cyclone are C-like and statically typed, but their compilers are less mature.
> That functional programming contest where > O'Camel wins every year even though it is by far > the slowest entry is a complete crock of shit. > The winning O'Camel entry ran 1000 times slower > than the equivalent correct C++ entries.
This is totally wrong. Where are you getting this from? I defy you to show me O'Caml code that is even 10 times slower than the equivalent C code. O'Caml is typically no worse than twice as slow as C, often around 20% slower, and sometimes even faster (high level languages have some advantages over C for optimizations). Check out Doug Bagley's benchmarks for some actual measurements. (http://www.bagley.org/~doug/shootout/craps.shtml)
(Sounds like you need to do some more learning!)
Re:Would be impossible in garbage-collected langua
by
jonabbey
·
· Score: 2
Re:It should be a warning
by
Panaflex
·
· Score: 2
My tips:
* Use electric Fence (Read the FAQ.. there's several levels of checking) * memprof is nice * When you free(), I always use a macro like so.. #define FREE free(x);x=NULL * You can use the glib memory management as well, though there are some annoyances. But you get some freebie implementations of list, hash,sort, etc functions.
That way you get a nice clean segfault:-)
Enjoy the show.
Pan
-- I said no... but I missed and it came out yes.
Re:Would be impossible in garbage-collected langua
by
Tom7
·
· Score: 2
An AC
> Go to the functional programming contest site and look at the timings of the winning > entries and the language they are written in. The last contest was "compressing" a > hypothetical HTML-like markup language. The C++ entries ran in a few seconds, whereas the > O'Camel entries took several minutes to complete.
I competed in this contest, and I'm quite familiar with it and the performance of the various entries. (In fact, our Non-C entry placed 9th overall.) The performance of Non-C languages was very good in this contest. Anyway, the best one was written in Haskell, and that's because it had the best algorithm. Did you totally overlook this? I don't understand where you're getting these numbers from.
Of course, most of the C and C++ entries didn't even work.
Why are you posting anonymously?
Re:Gah! Stop this stupid argument!
by
jilles
·
· Score: 2
IMHO 95% of C development because of performance reasons is not based on any factual evidence for performance gains. I've noticed people use C just to be sure rather than that they are experiencing actual performance problems. To make things worse: there appear to be a lot of myths about performance and most C programmers I've seen are rather stubborn and not particularly sensitive to perfectly good argumentation.
Also there are much more safe languages than C that can be just as fast as C. Somebody already mentioned ADA, lets also mention Eiffel. Not using those in system that needs to be secure is almost criminal given the near certainty of buffer overflows.
Once again, I have seen http servers, mail servers, ldap servers written in 100% Java performing at a very acceptable level. I too would like to see fast implementations of zlib, I don't see how this cannot be done in another language than C.
Maybe 1% of the code actually requires some of the dirty trickery in C (I'm very sceptical of this need) but that doesn't mean you need to implement the other 99% of the code in C as well.
You list a few interpreted and just in time compiled languages. It is commonly known that these are slower than compiled languages than C (even though they are getting awfully close performance wise). However you can do stuff like bounds checking and garbage collection in statically compiled languages as well.
--
Jilles
Re:Would be impossible in garbage-collected langua
by
partingshot
·
· Score: 2
> So what's keeping us?
Industry is slow to adopt and most coders are not trained as computer scientists.
The majority of 'new' technology we use today has been around in the academic world for decades.
-- Anonymous posts are filtered.
Re:Would be impossible in garbage-collected langua
by
lkaos
·
· Score: 2
Why do you think this is hard? There are plenty of user-level single-threaded garbage collectors, even real-time ones. I don't think it would be hard to do, and would even have some benefits, like heap compaction, that are important for long-running programs like an OS kernel.
Step back and think a moment about what you just said. Garbage collection makes no guarentees about when GC will actually occurs. That means every time kalloc was called, there would be the potential for it to sleep while the GC searched the reference tree. This is absolutely no good for the kernel. Not to mention the fact that there are three distinct types of memory within the kernel so three GC would be required.
Garbage collection is not the end all solution to memory mangagement _especially_ when you have to make guarentees about performance. Reference counting is being slowly implemented within the kernel and this is likely to be the best mechanism to solve memory issues.
Not to mention the fact that most kernel data structures simply cannot afford the overhead required by a garbage collector (since kernel memory constantly occupies RAM and therefore eats away at the available amount of system memory).
Garbage collection works for large programs that don't really have speed considerations. It does not work in every situation though.
OK, so perhaps if libz is necessary in the kernel, then we have no choice but to write it in C. I am kind of surprised that libz is linked in there, actually. How does it call malloc()/free() if it's in the kernel?
The zlib_inflate and zlib_deflate routines do not call malloc()/free(). Instead, they take in memory from the caller that is usually allocated with valloc or kalloc. It's important to note that the zlib is not linked against the kernel, but a portion of zlib exists within the kernel as a derivative.
Compression/Decompression is inherently a costly operation. It fortunately though is not one that requires a great deal of allocation/deallocation. Therefore, there is no justification for adding the overhead of a complex memory tracking system.
Besides, as many posters pointed out, there is a mechanism in LIBC to allow memory to be tracked dynamically. The performance trade off is just not exceptable though. So called high level languages are not the solution to every problem.
--
int func(int a);
func((b += 3, b));
Re:Would be impossible in garbage-collected langua
by
Tom7
·
· Score: 2
> Step back and think a moment about what you just said. Garbage collection makes no > guarentees about when GC will actually occurs. That means every time kalloc was called, > there would be the potential for it to sleep while the GC searched the reference tree. > This is absolutely no good for the kernel.
Actually, there are several real-time garbage collectors around. It's not at all impossible to have a real-time one with low overhead (lower than certain mallocs), and still win in terms of ease of use, correctness, and heap compaction. Don't forget that malloc implementations also need to do things like coalescing that can cause an alloc or free to "sleep" (that is, take a while) too!
Anyway, I wasn't *really* suggesting retrofiting linux with a garbage collector. They already do a pretty good job of memory management. I'm just saying that for a new kernel, the idea of GC is not so preposterous. Not all garbage collectors act like emacs lisp or the JVM.
> The zlib_inflate and zlib_deflate routines do not call malloc()/free()
This is interesting. If so, then how can the kernel be subject to this double-free bug? (Some people were claiming that.)
> Compression/Decompression is inherently a costly operation. It fortunately though is not > one that requires a great deal of allocation/deallocation. Therefore, there is no > justification for adding the overhead of a complex memory tracking system.
I don't think this follows. You mean overhead in terms of complexity or in terms of run-time? If it doesn't do much allocation, then (supposing the garbage collector imposes a significant performance hit) it will not be impacted much by a garbage collector. If you are talking about code complexity, well, it would certainly be overkill to implement a garbage collector just for that one library, but I'm not suggesting that. I'm suggesting that we use high level languages where possible, particularly ones with garbage collectors -- in this case it SIMPLIFIES the code. In fact, here it would remove a potentially exploitable bug.
> Besides, as many posters pointed out, there is a mechanism in LIBC to allow memory to be > tracked dynamically. The performance trade off is just not exceptable though. So called > high level languages are not the solution to every problem.
It's not fair to compare the performance of debugging LIBC calls to the performance of an optimized safe high-level language. But either way, I don't think any "tradeoff" that sacrifices correctness for speed is really a "tradeoff", it's just a mistake.
Re:Would be impossible in garbage-collected langua
by
lkaos
·
· Score: 2
Actually, there are several real-time garbage collectors around. It's not at all impossible to have a real-time one with low overhead (lower than certain mallocs), and still win in terms of ease of use, correctness, and heap compaction. Don't forget that malloc implementations also need to do things like coalescing that can cause an alloc or free to "sleep" (that is, take a while) too!
malloc/free are _not_ used in the kernel. The kernel doesn't really have VM in the traditional sense. Garbage collection works when you have an underlying VM because unused memory is swapped to disk and therefore has no real performance penality. So, if a GC holds on to 50MB of unused memory, so what? It will get swapped to disk.
No so in the kernel though. It is vitally important that memory be free'd as soon as it can so that more RAM is available to applications. Now, having a VM in the kernel would not solve the problem because there would be a performance nightmare if kernel code had to be swapped in from disk.
I'm suggesting that we use high level languages where possible
The only area I disagree with you is on whether it is possible to use a high level language in the kernel. I do not believe it is. Now, with a microkernel, things are a bit different because there is a much more vague line between what is and isn't the kernel so there may be room for arguement there, but for the standard monolithic kernel, high level code just has to much overhead to be effective.
But either way, I don't think any "tradeoff" that sacrifices correctness for speed is really a "tradeoff", it's just a mistake.
What is truely needed is a mechanism to perform allocation/deallocation during compile time instead of run time. A mechanism to determine when a pointer is no longer valid and then inserts a deallocation within the code at that point. Solving poor programming during run-time is just a bad idea.
--
int func(int a);
func((b += 3, b));
Re:Would be impossible in garbage-collected langua
by
Tom7
·
· Score: 2
Again, I'm not really suggesting a garbage collector in the kernel, nor trying to write a monolithic kernel in a high level language. I think both would be possible, but they don't fit into the model that's currently used in, say, linux. I basically agree with what you're saying.
Is it really true that malloc and free are not used in the kernel? I thought there was like kmalloc and kfree that acted just like those, and I would assume they are implemented in a similar way. I don't know, I've never actually worked on the linux kernel, but when I did my own kernel in school I had stuff like that.
>> But either way, I don't think any "tradeoff" that sacrifices correctness for speed is >> really a "tradeoff", it's just a mistake. > > What is truely needed is a mechanism to perform allocation/deallocation during compile > time instead of run time. A mechanism to determine when a pointer is no longer valid > and then inserts a deallocation within the code at that point. Solving poor programming > during run-time is just a bad idea.
Garbage collection doesn't solve "poor programming"; it's a feature that a language offers that makes it easier to write programs. Of course, you can write poor programs in a language with any set of features.
But, a mechanism that is as you describe is "regions". You might read about that; it's a totally compile-time memory allocation inference scheme. (Unfortunately it is somewhat less flexible than garbage collection, but it does perform well.)
Re:Would be impossible in garbage-collected langua
by
lkaos
·
· Score: 2
Is it really true that malloc and free are not used in the kernel? I thought there was like kmalloc and kfree that acted just like those, and I would assume they are implemented in a similar way. I don't know, I've never actually worked on the linux kernel, but when I did my own kernel in school I had stuff like that.
kmalloc/kfree are much like their malloc/free counter parts. kmalloc/kfree return pointers to logical kernel memory. Logical kernel memory is usually directly accessable but not always. It usually corresponds directly to hardware memory (usually differing only by an offset). There are other functions (vmalloc, etc.) that return virtual kernel memory which is more like the memory returned by malloc. Virtual memory cannot usually be accessed directly.
The memory model in the kernel is much different in that it allows both fragmented allocation and page allocation. O'Reilly has a great book Linux Device Drivers that is actually under the GNU FDL and is available online at O'Reilly's homepage. There is a chapter devoted to kernel memory in it.
Garbage collection doesn't solve "poor programming"; it's a feature that a language offers that makes it easier to write programs. Of course, you can write poor programs in a language with any set of features.
If good programmers weren't penalized by it, then I would full heartily support garbage collection. Languages should not sacrifice in order to support user-error. The fact that it doesn't eliminate error only helps my point. Take the following:
In Java:
{
String a = new String("test");
String b = new String("test2");
a = b; }
In C++:
{
String a = "test";
String b = "test2";
a = b; }
Neither piece of code has a memory leak. Used properly, C++ is just as easy to use as Java. You have to _try_ and leak memory in C++, it doesn't happen automatically. Java prevents this by penalizing good programmers. That's my problem with it.
--
int func(int a);
func((b += 3, b));
Re:Would be impossible in garbage-collected langua
by
lkaos
·
· Score: 2
Much more important is correctness, and as we see time and time again, even "good programmers" make mistakes that can sometimes be devastating.
I don't think you see my point. Most objects simply belong on the stack. That doesn't happen in Java. In fact, that is exactly why there is a stack, to provide automatic memory management.
As for a tree example, that's what containers are for. One can build a tree in C++ without ever calling an allocation function.
It is possible to prevent new from being called on an object, and it is also possible to disable the global new. A programmer could conceivably disable these things and thereby never have to worry about memory leaks. Allocating dynamic memory is not always the answer and is much, much slower than just using the heap.
My point is not just that C++ is good for good programmers, but a good C++ architecture can prevent bad programmers from doing bad things. The only difference between C++ and other high level languages is that it gives you the option to do dangerous things. It's really a matter of programmers not knowing their limitations.
Heap compaction is not nearly that important unless there is a great deal of allocation. For most long running programs, allocation is rarely continuous. Usually, it is periodic, in which, heap compaction does very little.
--
int func(int a);
func((b += 3, b));
Re:Would be impossible in garbage-collected langua
by
Tom7
·
· Score: 2
> I don't think you see my point. Most objects simply belong on the stack. That doesn't > happen in Java. In fact, that is exactly why there is a stack, to provide automatic memory > management.
Well, unfortunately Java has pretty dumb implementations. Some of my favorite implementations of garbage-collected languages like SML can allocate on the stack, and often do.
> Allocating dynamic memory is not always the answer and is much, much slower than just > using the heap.
What is the difference between "allocating dynamic memory" and "using the heap"? You mean the stack, right? (Otherwise I am confused..)
> Heap compaction is not nearly that important unless there is a great deal of allocation. > For most long running programs, allocation is rarely continuous. Usually, it is periodic, > in which, heap compaction does very little.
I'd be interested in hearing your reasoning behind this. I believe that heap compaction helps especially in cases of long running programs that do infrequent allocation but have long-lived data (the common case for long-running programs). A garbage collector can reclaim fragmented space in the heap that would be impossible to reclaim through standard uses of malloc. This reduces the working set and increases locality (for caches) which are of course good for performance.
Re:Would be impossible in garbage-collected langua
by
lkaos
·
· Score: 2
I'd be interested in hearing your reasoning behind this. I believe that heap compaction helps especially in cases of long running programs that do infrequent allocation but have long-lived data (the common case for long-running programs).
In practice, that data is usually either large quanities of initialization data though. Or, it's a bunch of small allocations that are likely continuous.
Most long running programs are daemons, and essentially start up, initialize data, and then enter a repeative state loop. There isn't really that much fragmentation in the initial data so compaction doesn't really buy much.
Compaction is only useful when a program is generally allocating small bits of memory where most - but not all of it - is freed after being used. Most programmers go to great lengths to avoid frequent allocations so this is why this behavior does occur frequently.
Now, in a language like Java where memory is allocated far more often then it should, you run in to a circumstance where compaction is required.
--
int func(int a);
func((b += 3, b));
Re:It should be a warning
by
Panaflex
·
· Score: 2
libglib can be compiled with rudamentary mem checking. (See g_mem_profile and g_mem_check).I've also found that using glib sometimes makes memprof much happier than malloc/free. Memprof does not like openssl though! Pan
-- I said no... but I missed and it came out yes.
Re:It should be a warning
by
Panaflex
·
· Score: 2
My macro works fine thanks. Yes, I am aware of ways in which it will not work but c'est la vie.
Slashdot Mirror
could somebody point out where in the source this is? the article was fluff.
https://www.accountkiller.com/removal-requested
This article gives more information, and links to vendor advisories: http://www.linuxsecurity.com/articles/security_sou rces_article-4582.html.
-mark
If your computer says LINUX, run...computers can't talk! [unless you have text-speech software]
Some More Links.
zlib is not os dependent. Many Windows based products/projects use it as well. Is there some linux specific issues related to this overflow issue?... or is it just a headline hype thing
Owen Taylor at RedHat found the bug. He works on GTK among other things, as you can see from the GTK+ release notes he posted earlier this month: mail.gnome.org/archives/gtk-devel-list/2002-March/ msg00161.html
http://tinyurl.com/4ny52
On the stuff I've been reading about finding and fixing buffer overflows, it seems like it's generally not too hard to spot where these things could potentially happen.
My question is this: How feasible would it be for someone to take a computer and have it do nothing but pattern-matching through all the source code in a typical Linux distribution, looking specifically for problem areas like these? Obviously we couldn't rely on it as a foolproof audit, but has something like this ever been considered?
--------
Bleah! Heh heh heh... BLEAH BLEAH!!! Ha ha ha ha...
The advisory for zlib-1.1.3 is at:
i b Advisory 2002-03-11
1 .4 .tar.gz
http://www.zlib.org/advisory-2002-03-11.txt
Zl
zlib Compression Library Corrupts malloc Data Structures via Double Free
The new zlib (1.1.4) is at:
ftp://ftp.info-zip.org/pub/infozip/zlib/zlib-1.
Did this get released early? I got the RedHat advisory, but there is no source update at zlib.org, the CVE page at Mitre is empty and there is nothing from CERT yet.
What gives? Does anyone know where a patch is available?
Do you even know anything about perl? -- AC Replying to Tom Christiansen post.
As I'm not a programmer, what can I grep to search stuff I've compiled from source to determine what's using staticly linked zlib?
And the site seems to be suffering from the /. effect. Either that or they didn't patch and someone took advantage of the exploit.
STOP MISUSING APOSTROPHES, YOU MORONS!!!
Duplicate deletions are not the same as buffer overflows and are no where near as easy to exploit. In fact, I have _never_ seen a duplicate deletion exploitation other than a simple DoS. Not to mention the fact that it requires a special series of calls from the calling program.
In summary, the world hasn't come to an end and Free Software is all-the-sudden as vunerable as closed source software. Put the pills down and relax
int func(int a);
func((b += 3, b));
Quake 3, for example, statically links zlib in to deal with decompressing pk3 (zip) files. If the client auto-download is on, pk3 files can be downloaded from the quake server.
I don't mean to be an alarmist, but this is something that should be considered. Zlib is linked into Quake 3 on all platforms.
This is creepy. I was wondering about possible vulnerabilities in zlib earlier today for a completely different reason.
According to this post in a different article, a recent patch to Internet Explorer disables support for gzip encoding. Do you think, perhaps, Microsoft noticed the bug, shut off the support (since presumably they're just using zlib also), and just didn't say anything?
Of course, that is just paranoia. They could have plenty of other reasons.
--JoeProgram Intellivision!
The article says that the kernel is affected - does it statically link zlib, in which case a recompile is in order, or do I just need to upgrade the zlib package?
Or is the article lying?
Is it just me, or have there been a really huge amount of security issues with Free/Open Source software this year?
It just seems like there's a new hole (or two) every week. Let's see, we've had openssh, zlib, php, mod_ssl, cvs, cups, rsync, exim, ncurses, glibc and more, just since January. We've still got two-thirds of the year to go. Anyone want to make bets on what other projects will get hit? I think we're going to see problems with XFree86, samba, and apache.
So, my question is this: Do you think that this is simply a bad time for FS/OSS security? Are we at the threshold where there are enough eyes on the code to locate these kinds of bugs? Or is the quality of FS/OSS declining?
Thankfully the 9000 lines of regularly coped and pasted source commonly known as zLib does not infest the MacOS universe or mac servers at least.
:
The MacOS running WebStar as a server has never been exploited.
In fact in the entire securityfocus (bugtraq) database history there has never been a Mac exploited over the internet remotely.
That is why the US Army gave up on MS IIS and got a Mac with WebStar.
I am not talking about BSD derived MacOS X (which already had a couple of exploits) I am talking about Mac OS 9 and earlier.
Why is is hack proof? These reasons
1> No command shell. No shell means no way to hook or intercept the flow of control with many various shell oriented tricks found in Unix or NT
2> No Root user. All mac developers know their code is always running at root. Nothing is higher (except undocumented microkernel stufff where you pass Gary Davidians birthday into certain registers and make a special call). By always being root their is no false sense of security.
3> Pascal strings. ANSI C Strings are the number one way people exploit Linux and Wintel boxes. The mac avoids C strings historically in most of all of its OS. In fact even its roms originally used Pascal strings. As you know pascal strings are faster than C (because they have the length delimiter in the front and do not have to endlessly hunt for NULL), but the side effect is less buffer exploits.
4> Stack return address positioned in safer location than intel. Buffer exploits take advantage of loser programmers lack of string length checking and clobber the return address to run thier exploit code instead. The Mac places return address infornt of where the buffer would overrun. Much safer.
5 : Macs running Webstar have ability to only run CGI placed in correct lodirectoy cation and correctly file typed.
6> Macs never run code ever merely based on how a file is named. ",exe" suffixes mean nothing. For example the file type is 4 characters of user-invisible attributes, along wiht many other invisible attributes, but these 4 bytes cannot be set by most tool oriented utilities that work with data files. For ecxample file copy utilities preserve launchable file-types, but JPEG MPEG HTML TXT etc oriented tools are physically incapable of creating an executable file. the file type is not set to executable for hte hackers needs. In fact its even more secure than that. A mac cannot run a program unless it has TWO files. The second file is an invisible file associated with the data fork file and is called a resource fork. EVERY mac program has a resource fork file containing launch information. It needs to be present. Typically JPEG, HTML, MPEG, TXT, ZIP, C, etc are merely data files and lack resource fork files, and even if the y had them they would lack launch information. but the best part is that mac web programs and server tools do not create files with resource forks usually.. TOTAL security.
7> There are less macs, though there are huge cash prizes for craking into a MacOS based WebStar server. Less macs means less hacvker interest, butthere are millions of macs sold, and some of the most skilled programmers are well versed in systems level mac engineering and know of the cash prizes so its a moot point, but perhaps macs are never kracked because there appear to be less of them. (many macs pretend they are unix and give false headers to requests to keep up the illusion, ftp http, finger, etc).
8> MacOS source not available traditionally, except within apple, similar to Microsoft source availability to its summer interns and such, source is rare to MacOS. This makes it hard to look for programming mistakes, but I feel the restricted source access is not the main reasons the MacOS has never been remotely broken into and exploited.
Sure a fool can install freeware and shareware server tools and unsecure 3rd party addon tools for e-commerce, but a mac (MacOS 9) running WebStar is the most secure web server possible and webstar offers many services as is.
I think its quite amusing that there are over 200 or 300 known vulenerabilities in RedHat over the years and not one MacOS remote exploit hack. And Now ith zLib, even more holes can be found in Linux.
You have a point. Maybe this is MS intention of C# to avoid their own problems with just this issue. (I am of course joking we all know world domination throught IT enslavement is the real goal)
But a point you may be missing is MANY of the languages are built on C and as a result in effect inherently unsafe as well, unless they are self hosting.
Sig went tro...aahemmm.....fishing........
Well, it won't prevent the DoS aspect - but, from the malloc manpage:
Recent versions of Linux libc (later than 5.4.23) and GNU libc (2.x) include a malloc implementation which is tunable via environment variables. When MALLOC_CHECK_ is set, a special (less efficient) implementation is used which is designed to be tolerant against simple errors, such as double calls of free() with the same argument, or overruns of a single byte (off-by-one bugs). Not all such errors can be proteced against, however, and memory leaks can result. If MALLOC_CHECK_ is set to 0, any detected heap corruption is silently ignored; if set to 1, a diagnostic is printed on stderr; if set to 2, abort() is called immediately. This can be useful because otherwise a crash may happen much later, and the true cause for the problem is then very hard to track down.
Seems worth it while all pour through the symbol tables of our static binaries (and recompile the stripped ones. =( )
On another note, I've always regarded security bulletins as a one-way process... For example, I couldn't find a way to tell RedHat they'd omitted this (seemingly important?) reminder. Any thoughts about this? (admittedly i didn't look very hard for very long)
Erm, I hate to ruin your little world and all, but FreeBSD uses zlib, too.
--
I Hit the Karma Cap, and All I Got Was This Lousy
And it seems they arent too a shame to tell they made mistakes ;)
But to answer your last question, its seems its only getting better with finding all these bugs and all.
OpenSSh uses zlib - if you happen to compile OpenSSH statically with zlib (I think thats the default), one more upgrade cycle after the latest OpenSSH 3.0.2p1 bug... :(
I think it does hit FreeBSD. FreeBSD uses zlib v1.1.3. v1.1.4 has the fix (http://www.gzip.org/zlib/). No security announcement has arrived in my mailbox, yet I expect it soon.
So, you should download the patched zlib, but you should also email the glibc maintainers and demand that they implement a sane, error-checking malloc()/free() system. Linux's current allocation model is a disaster waiting to happen.
Loneliness is a power that we possess to give or take away forever
I bet you are one of the ppl that instantly criticizes when you hear that M$ (or insert fav evil corp) knew about a vulnerability and kept it quiet for a month.
Damned if ya do...
---"What did I say that sounded like 'Tell me about your day?'"---
Sounds like that disaster you speak of did just happen. Well, maybe not quite a disaster, but anytime I have to upgrade 20+ packages for one bug, that's bad.
This sig has been temporarily disconnected or is no longer in service
Is it just me, or have there been a really huge amount of security issues with Free/Open Source software this year?
Yes; perhaps this is due to the fact that FS/OSS is used by more developers/users. More eyeballs and more code to exercise libraries mean more bugs are discovered. As mentioned, this bug is (relatively) benign, and has already been fixed in the source. So I wouldn't necessarily say that FS/OSS is getting "more buggy", any more than commercial software, whose bugs don't leave the company if users don't discover them first.
No, it's not the site, it's the poster who is suffering from the /. effect (actually, syndrome). The /. syndrome is: post as fast as possible and get tons of karma from moderators who don't check the links.
This is why you ALWAYS set a pointer to NULL after freeing it, even if it's "totally unnecessary" because you're about to free the structure holding the pointer.
This doesn't prevent attempts to free the previously freed pointer, but that will generally do a lot less damage than freeing a real malloc'd address. And during development it's trivial to add an assertion checking for a NULL pointer before any free().
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
Yet why in the name of all that is good do they not realize that C is an inherently unsafe language. There are some really good free alternatives to C, so why the heck are those numbskulls not using them?
Because most distributions of GNU/Linux operating systems don't install any compiled languages but C and C++. (There is no language called "C/C++".)
Because popular libraries have C bindings.
Because compilers can optimize C code for machines with limited resources. (Java technology is a memory hog partly because of the 16-byte overhead of java.lang.Object.)
Because people think in "step 1, step 2, step 3" of an algorithm, rther thn in functionl style (partially ruling out CL, ML, and Haskell).
Take your choice: Eiffel, Ada, Modula-3
Which of these languages is in the default devel install in all the major distros and can link to libraries' C bindings?
Will I retire or break 10K?
This bug was not reported on Bugtraq yesterday. In fact, it's not been mentioned on Bugtraq at all yet.
Why Linux can't follow in the supposedly-inferior BSD's footsteps is beyond me.
Loneliness is a power that we possess to give or take away forever
Part 2: packages containing libz/zlib
From part 2:
Timeo idiotikOS et dona ferentes
Not that quick... this was a coordinated release of the bug Owen Taylor at Red Hat found by investigating a bug against Gnome. This wasn't found yesterday, vendors have had time to create and test packages.
Its mostly because a certain large vendors publicity machine keeps pushing any bug report that impacts open source in the slightest as a big thing and feeding it to the press.
Dirty game really, but thata how they play it.
This is why news stories keep starting with Linux blah and then turning into "everyone blah"
If they ripped them off as you say they would not be able to licence them as GPL now could they?
sure they could. The BSD license lets anyone do whatever they want, including relicense the code as GPL. There is already BSD code in the Linux kernel.
cpeterso
The assertion being tripped would, however, be a useful diagnostic if you prefer to know when something is being freed twice. For instance, if there exist two separate pointers to an object, which itself contains a pointer that gets set to NULL when freed, a well-placed assertion would tell you if you've got a logical error -- trying to deallocate a dangling pointer, basically.
Simply clearing it to NULL means that such won't be found, which may hide related errors. Letting it be freed twice would simply be sloppy and asking for trouble.
Only the dead have seen the end of war.
While it's annoying to discover a buffer-overflow problem (or whatever; I haven't examined the report closely) in Linux and other OSS, if you ever wanted confirmation that Linux is being taken seriously by the public at large, it's that c|net thought a Linux bug worthy of reporting. Has that ever happened before?
The assertion lets you catch the logic error that led to the second free during debugging. Presumably, your code path wasn't expecting the pointer to already be free at that point; otherwise, you would have designed it to handle that case already.
Then, in production code, if you do take that path, you'll get the harmless no-op free(0). (You do build production with -DNDEBUG, right?)
Did you come up with that one? Well put. I may have to make that my sig, I feel the same way, wish I had thought up that one.
I'm the big fish in the big pond bitch.
My count of 20 packages is based on the warning redhat distributed. They recommend upgrading some 22 packages on a Redhat 7.2 system. This includes several packages for the kernel, zlib itself, and a number of other applications that are statically linked such as cvs, dump, etc.
The scary thing is, I may have installed other apps that have zlib statically compiled that I don't even know about because they aren't part of the default vendor distribution.
This sig has been temporarily disconnected or is no longer in service
Well lets look.
Linux:
1. Flaw Found
2. Flaw fixed for current and previous distributions.
Windows
1. Flaw found
2. Flaw claimed to be feature
3. Large Corporation bothered by flaw
4. Flaw patch developement begins.
5. Beta release of flaw pack
6. Beta 2 release of flaw pack
7. RC1 of flaw pack
8. Flaw pack released for new OS products
9. 1 month later flaw pack released for most widely used OS version.
Get a free ipod.
On Linux : add this at the beginning of your /etc/rc file and in your shell init scripts :
.
:
/etc/malloc.conf
export MALLOC_CHECK_=2
(don't forget the extra underscore at the end)
On BSD systems
ln -s ZH
It will protect both your statically and dynamically linked apps. It adds a little performance penalty, but it's really not noticeable.
{{.sig}}
When I left my comment, it wasn't there. :)
:)
I guess it is only partially immune: http://www.kb.cert.org/vuls/id/368819. Reading the security list I gather that it is only a problem with regards to running Linux apps. Time to give FreeBSD's free() a hug.
#define NULL 5
while(1)
{
if (x=*NULL)
break;
}
The TCP stack for almost all OS's was {stolen|borrowed|based on} the TCP stack in BSD 4.x (IIRC). I remember once, a few years ago, a system engineer did a special sequence on a Windows 98 computer, and got the BSD copyright to show up.
VM in Linux is a mess. 2 (very) different VM systems, that cause quite a few utilities to be re-writtian. All of the BSD's have one each, and they optimize their VM quite well. FreeBSD has a very robust one, that is a bit slower than Linux's, but seems to be more stable.
OpenBSD just got statefull firewall with the latest version (3.0) Prior to that, they were using Darren Reed's IPF, but due to a licensing fiasco (and petty name calling), IPF was yanked, and PF was created. I use PF in my firewall at home, and I am quite happy. I can't wait until 3.1 (not willing to run -current) to see how much more robust it can get. =)
Problem: What if you have a structure that *optionally* allocates memory, and your cleanup code for that structure just frees all the pointers?
I have never bothered to check free because my rule is: for every init of a structure, make sure you call the cleanup.
This has worked for hundreds of kLOC of C I've written. Also, debugging heaps are nice. :)
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
Because when closed source software (not limited to just MS) has a security bug it was found because somebody managed to exploit it. When you find bugs in open source software you don't have to find them with an exploit, you can find them with your eyes.
Matt. Want XML + Apache + Stylesheets? Get AxKit.
If you have to remotely upgrade the zlib library, be *very careful* .
Because SSH/OpenSSH depend on zlib, if you replace your current libz.so file with another version whoose API has a bit changed, your SSH server won't work any more.
So if you don't have access to the console, open a classical 'telnet' port for a few minutes, just during the upgrade. Once you've checked that SSH is still ok, you can remove the telnet daemon.
If SSH doesn't work any more after the zlib upgrade, recompile SSH.
{{.sig}}
If you read the redhat advisory you will see. And we are talking RedHat here Dude.
* Relevant releases/architectures:
Red Hat Linux 6.2 - alpha, i386, i586, i686, sparc
Red Hat Linux 7.0 - alpha, i386, i586, i686
Red Hat Linux 7.1 - alpha, i386, i586, i686, ia64
Red Hat Linux 7.2 - i386, i586, i686, ia64
*
Followed by the direct link to the updates for all the above distributions dude !
Get a free ipod.
If any of you are running late model, production Red Hat servers for any purpose, I expect you probably heard about this way before today.
Users of Red Hat Linux 7.1, or 7.2 should update to the currently released kernel errata RHSA-2002-028 (2.4.9-31) which already contains this fix.
Kernel 2.4.9-31 was released by Red Hat well over a week ago. There were patches released for earlier distros as well. If you're not using the up2date program to perform system updates then you should at least be using it to check when packages become available.
So, yes, there is a problem with zlib. But if you have good administrative practices you have either taken care of this already, or have a formulated plan to deal with it. Either way, this should not be news to a decent Red Hat administrator.
I'm against picketing, but I don't know how to show it.
Shouldn't that be 'src' instead of 'SRPMS'?
--
The Cap is nigh. Time to get a fresh new account.
So just keep an SSH session open until your sure the upgrade went OK. No need to hand out your passwords over telnet.
-- ;-)
Kuro5hin.org: where the good times never end.
Windows, Smart? What bullshit, unless things have changed since 98. I've written programs that did the double free thing and never saw an error message other than my or some other program freezing up. With all the "uber-patches" and what not M$ needs monthly, I just don't think that is so.
The only insecure thing I do with my home network is use a windows machine at work to log into it. Apt-get update and upgrade, all fixed in ten minutes before I go home. I'm going to have to call the folks at Red Hat to figure out up2date when I get home, sigh. The M$ box that I have to use for cameras and a scanner? It's blind to the network and usually runs Red Hat. IE? Eye-EEEEEeeee!
Friends don't help friends install M$ junk.
Sorry, I must have gotten confused with all those viruses like code red, nimida, sircam, and countless minor expoits for M$ OS. Ha Ha!
Friends don't help friends install M$ junk.
I dunno, most double frees come from freeing DIFFERENT copies of a pointer. Setting one to NULL won't help in this case...
;))
(A much better solution is to use a garbage collector.
In a recent reverse engineering session, I noticed that Internet Explorer uses zlib! myria
"Screw Sun, cross-platform will never work. Let's move on and steal the Java language." - Visual J++ Product Manager
Cool but it still bugs me when people say Linux just stole it's TCP/IP, VM etc from BSD.
They never offer any evidance of it and all it serves to do is belittle the efferts of the linux community.
I understand that these people don't represent the BSD community. It's still anoying though.
I'm verry thankfull for what Linux/GNU has given me for free.
how else would a kid like me get access to UNIX a C compiler etc.
And if the BSD community supplied any of that they diserve there props too.
But the guy didn't have to be a dick about it is all I'm trying to say .
I know I'm going to hell, I'm just trying to get good seats.
Troll? Bah, more like a zealous moderator. Like it or not, I stand by my statement: the irony is funny. If you can't see that, pull your head out of your kernel and get a life.
https://www.accountkiller.com/removal-requested
Perhapse you'd like to catch up on recent events with OpenSSH? Yes. The one from OpenBSD.
Yes, if security is your main concern, one should consider OpenBSD. And their creating of OpenSSH is a great service towards the entire open source (heck - IT / infosec) community. But lets not use it in a lame attempt at a flame war.
Like most recent security holes in linux software, this one would be unexploitable in a modern safe language. (In fact it would be *impossible* to make this error in a garbage-collected language!)
The typical response I hear to this kind of comment is that "high level languages are inefficient". (I don't belive this is true, but most other people here do.) But whatever, let's pretend they are.
Now, what kind of crazy world do we live in where we value performance more than correctness (security)?? We are seeing more and more security holes as we try to write bigger and bigger packages in C. Why do we accept this? Who here really cares more about the performance of zlib than the time it takes for them to patch all of their statically-linked software, and their risk of being rooted until they do? I sure don't.
Forget about all this "coding practices" stuff. It simply takes too much effort to produce bug-free code in C. The OpenBSD people, kings of code review, just had an exploitable bug in sshd! While we need to use C for some tasks (ie, most parts of the kernel), I think we are seriously unpowered to do this for most applications (as evidenced by the high number of simple errors made, and sometimes caught).
If we simply wrote our software in high level languages, we would automatically rule out the largest classes of security holes, which would give us a lot more time to work on more important things, like high level architecture review and optimizations. I think we'd end up with a better system. So what's keeping us?
For more discussion, see our big argument in the story about the OpenSSH root hole. http://slashdot.org/comments.pl?sid=29123&cid=3124 957
Unfortunately, most code isn't reviewed (or if it is, it's not reviewed carefully). I think it's just a myth that openness implies more review. (One might even make the argument that openness causes laziness!)
In fact, the very first piece of linux code I looked at carefully (the MD5_crypt code in PAM) had some very obvious mistakes in it. Anyone actually auditing it should have noticed it. And this is a highly security-critical piece of code!
I'm not saying that open source doesn't have its benefits (it certainly does), but simply making something open doesn't make the code better. People have to actually review it, and they seldom do.
Ok, explain to me how one is going to implement a Garbage Collector in the kernel?
If libz was written in anything other than C, it could not be used in nearly as many applications as it is currently.
int func(int a);
func((b += 3, b));
Another (?) AC flames,
> Yeah, and Java VMs don't also have coding errors.
> You must be the only Java user in the world not
> have their JVM app crash on them for no reason.
> The Hotspot JVM is written in C++ and is also
> subject to these same types of issues.
The fact that you immediately think I must be talking about Java shows that you need to do some more learning. There are many high-level, safe languages! (And Java is about 30 years behind the best of them...) For instance, check out O'Caml for a natively-compiled, yet safe language.
Either way though, writing more code in a safe language reduces the size of your trusted code base, and this makes it easier to audit your code.
In retrospect, this seems like negligence. But it only reflects the concenrns and the focus of C/C++ at the time : Speed.
The latest XFree comes with a copy of zlib 1.0.8.
/usr/X11R6/lib/libz.a on
Does anybody know where this is used and whether I should do a rebuild with the current 1.1.4 version?
In addition to gs, this seems to be the only software package that contains zlib in it. I found it because there is a
my Linux system.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted and ignored otherwise.
Yeah, so what? I know plenty of other languages, but if a client has a few million LOC in C the only thing they will do when I suggest changing to a "safe" language is thank me for my services and show me the door.
In contrast, I can usually get by with baby steps. Turning on compiler warnings and code hygiene to start, then assertions, etc.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
Sorry for showing my age. I learned C in '83 or so, and back then free() did not do special checks for NULL pointers. At least, not in some of the cheap-ass libraries we used!
I knew that C++ delete was NULL-safe, but I had forgotten that the C free() is also supposed to be NULL-safe now.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
That reminds me of a horror story I once heard. Fortunately it wasn't me....
This poor guy spent hours inspecting a parse tree after a core dump. He couldn't find anything wrong. Then, finally, he realized that he was looking at the *last* parse tree - the one that the system handled without a problem. The parse tree that caused the system to crash was a lot smaller and had an immediately obvious problem, but the address of the root node was just a little bit different from the address of the root node of the old parse tree. Something easily overlooked.
Starting that day this guy was religious about setting pointers to NULL, status flags to DELETED, etc., whenever he released an object.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
As long as you're not using a crap distro that statically links zlib all over the place, the fix for this is trivial. Install a patched zlib package and you should be pretty safe. The only instances of static zlib linking in Debian are:
amaya 2.4-1potato1
dictd 1.4.9-9potato1
erlang 49.1-10.1
freeamp 2.0.6-2.1
mirrordir 0.10.48-2.1
ppp 2.3.11-1.5
rsync 2.3.2-1.6
vrweb 1.5-5.1
So upgrade these too if you happen to use them. ppp would be the most critical of those for most people.
I think the traceroute hack is an example of freeing garbage, not a double-free(). The garbage being freed happens to be part of the command line, which is how the hacker injected his /bin/sh. The traceroute exploit description did not give full details, but I don't see how it could be possible to use modify ((int*)p)-1 using the zlib vulnerability. Remember that all mallocs are sizeof(8) aligned and have a minimum size of 16 (with overhead and internal fragmentation).
It is fully immune. Free|Net|OpenBSD are listed because they do use zlib and the same (already patched in Jan and Feb) bug exists. However, it's not exploitable because double-frees don't cause apps to segfault. THAT code was checked in (In FreeBSD) over 6 years ago.
--
My comments and opinions completely reflect those of anyone and anything I am remotely associated with.
I'll be sure to think of how horrible and inferior Microsoft is while I'm rebuilding my kernal and half my apps over the next few days. (Not to mention the fact that I still have OpenSSH on remote machines that need patching). Meanwhile, my wife hits Windows update every day and gets fresh binary patches with little effort.
No, one they stole, one they wrote themselves.
Linux didn't steal shit otherwise someone would post some code comparissions by now. It's not exacly hard to get the code (There both free for download).
So my message to you trolls is put up or shut up.
I want to see proof showing that the code used in the linux kernel was copyed from BSD.
Until then go fuck you self.
I know I'm going to hell, I'm just trying to get good seats.
An AC flames,
)
> Show me one such high level "safe" language with
> the performance and low-memory characteristics of
> C. Lisp? O'Caml? Scheme? Snobol? Please.
I'd say both SML and O'Caml fit that, yes. Also Popcorn and Cyclone are C-like and statically typed, but their compilers are less mature.
> That functional programming contest where
> O'Camel wins every year even though it is by far
> the slowest entry is a complete crock of shit.
> The winning O'Camel entry ran 1000 times slower
> than the equivalent correct C++ entries.
This is totally wrong. Where are you getting this from? I defy you to show me O'Caml code that is even 10 times slower than the equivalent C code. O'Caml is typically no worse than twice as slow as C, often around 20% slower, and sometimes even faster (high level languages have some advantages over C for optimizations). Check out Doug Bagley's benchmarks for some actual measurements. (http://www.bagley.org/~doug/shootout/craps.shtml
(Sounds like you need to do some more learning!)
Only four times?
- jon
Ganymede, a GPL'ed metadirectory for UNIX
My tips:
:-)
* Use electric Fence (Read the FAQ.. there's several levels of checking)
* memprof is nice
* When you free(), I always use a macro like so..
#define FREE free(x);x=NULL
* You can use the glib memory management as well, though there are some annoyances. But you get some freebie implementations of list, hash,sort, etc functions.
That way you get a nice clean segfault
Enjoy the show.
Pan
I said no... but I missed and it came out yes.
An AC
> Go to the functional programming contest site and look at the timings of the winning
> entries and the language they are written in. The last contest was "compressing" a
> hypothetical HTML-like markup language. The C++ entries ran in a few seconds, whereas the
> O'Camel entries took several minutes to complete.
I competed in this contest, and I'm quite familiar with it and the performance of the various entries. (In fact, our Non-C entry placed 9th overall.) The performance of Non-C languages was very good in this contest. Anyway, the best one was written in Haskell, and that's because it had the best algorithm. Did you totally overlook this? I don't understand where you're getting these numbers from.
Of course, most of the C and C++ entries didn't even work.
Why are you posting anonymously?
IMHO 95% of C development because of performance reasons is not based on any factual evidence for performance gains. I've noticed people use C just to be sure rather than that they are experiencing actual performance problems. To make things worse: there appear to be a lot of myths about performance and most C programmers I've seen are rather stubborn and not particularly sensitive to perfectly good argumentation.
Also there are much more safe languages than C that can be just as fast as C. Somebody already mentioned ADA, lets also mention Eiffel. Not using those in system that needs to be secure is almost criminal given the near certainty of buffer overflows.
Once again, I have seen http servers, mail servers, ldap servers written in 100% Java performing at a very acceptable level. I too would like to see fast implementations of zlib, I don't see how this cannot be done in another language than C.
Maybe 1% of the code actually requires some of the dirty trickery in C (I'm very sceptical of this need) but that doesn't mean you need to implement the other 99% of the code in C as well.
You list a few interpreted and just in time compiled languages. It is commonly known that these are slower than compiled languages than C (even though they are getting awfully close performance wise). However you can do stuff like bounds checking and garbage collection in statically compiled languages as well.
Jilles
> So what's keeping us?
Industry is slow to adopt and most coders are
not trained as computer scientists.
The majority of 'new' technology we use today has
been around in the academic world for decades.
Anonymous posts are filtered.
Why do you think this is hard? There are plenty of user-level single-threaded garbage collectors, even real-time ones. I don't think it would be hard to do, and would even have some benefits, like heap compaction, that are important for long-running programs like an OS kernel.
Step back and think a moment about what you just said. Garbage collection makes no guarentees about when GC will actually occurs. That means every time kalloc was called, there would be the potential for it to sleep while the GC searched the reference tree. This is absolutely no good for the kernel. Not to mention the fact that there are three distinct types of memory within the kernel so three GC would be required.
Garbage collection is not the end all solution to memory mangagement _especially_ when you have to make guarentees about performance. Reference counting is being slowly implemented within the kernel and this is likely to be the best mechanism to solve memory issues.
Not to mention the fact that most kernel data structures simply cannot afford the overhead required by a garbage collector (since kernel memory constantly occupies RAM and therefore eats away at the available amount of system memory).
Garbage collection works for large programs that don't really have speed considerations. It does not work in every situation though.
OK, so perhaps if libz is necessary in the kernel, then we have no choice but to write it in C. I am kind of surprised that libz is linked in there, actually. How does it call malloc()/free() if it's in the kernel?
The zlib_inflate and zlib_deflate routines do not call malloc()/free(). Instead, they take in memory from the caller that is usually allocated with valloc or kalloc. It's important to note that the zlib is not linked against the kernel, but a portion of zlib exists within the kernel as a derivative.
Compression/Decompression is inherently a costly operation. It fortunately though is not one that requires a great deal of allocation/deallocation. Therefore, there is no justification for adding the overhead of a complex memory tracking system.
Besides, as many posters pointed out, there is a mechanism in LIBC to allow memory to be tracked dynamically. The performance trade off is just not exceptable though. So called high level languages are not the solution to every problem.
int func(int a);
func((b += 3, b));
> Step back and think a moment about what you just said. Garbage collection makes no
> guarentees about when GC will actually occurs. That means every time kalloc was called,
> there would be the potential for it to sleep while the GC searched the reference tree.
> This is absolutely no good for the kernel.
Actually, there are several real-time garbage collectors around. It's not at all impossible to have a real-time one with low overhead (lower than certain mallocs), and still win in terms of ease of use, correctness, and heap compaction. Don't forget that malloc implementations also need to do things like coalescing that can cause an alloc or free to "sleep" (that is, take a while) too!
Anyway, I wasn't *really* suggesting retrofiting linux with a garbage collector. They already do a pretty good job of memory management. I'm just saying that for a new kernel, the idea of GC is not so preposterous. Not all garbage collectors act like emacs lisp or the JVM.
> The zlib_inflate and zlib_deflate routines do not call malloc()/free()
This is interesting. If so, then how can the kernel be subject to this double-free bug? (Some people were claiming that.)
> Compression/Decompression is inherently a costly operation. It fortunately though is not
> one that requires a great deal of allocation/deallocation. Therefore, there is no
> justification for adding the overhead of a complex memory tracking system.
I don't think this follows. You mean overhead in terms of complexity or in terms of run-time? If it doesn't do much allocation, then (supposing the garbage collector imposes a significant performance hit) it will not be impacted much by a garbage collector. If you are talking about code complexity, well, it would certainly be overkill to implement a garbage collector just for that one library, but I'm not suggesting that. I'm suggesting that we use high level languages where possible, particularly ones with garbage collectors -- in this case it SIMPLIFIES the code. In fact, here it would remove a potentially exploitable bug.
> Besides, as many posters pointed out, there is a mechanism in LIBC to allow memory to be
> tracked dynamically. The performance trade off is just not exceptable though. So called
> high level languages are not the solution to every problem.
It's not fair to compare the performance of debugging LIBC calls to the performance of an optimized safe high-level language. But either way, I don't think any "tradeoff" that sacrifices correctness for speed is really a "tradeoff", it's just a mistake.
Actually, there are several real-time garbage collectors around. It's not at all impossible to have a real-time one with low overhead (lower than certain mallocs), and still win in terms of ease of use, correctness, and heap compaction. Don't forget that malloc implementations also need to do things like coalescing that can cause an alloc or free to "sleep" (that is, take a while) too!
malloc/free are _not_ used in the kernel. The kernel doesn't really have VM in the traditional sense. Garbage collection works when you have an underlying VM because unused memory is swapped to disk and therefore has no real performance penality. So, if a GC holds on to 50MB of unused memory, so what? It will get swapped to disk.
No so in the kernel though. It is vitally important that memory be free'd as soon as it can so that more RAM is available to applications. Now, having a VM in the kernel would not solve the problem because there would be a performance nightmare if kernel code had to be swapped in from disk.
I'm suggesting that we use high level languages where possible
The only area I disagree with you is on whether it is possible to use a high level language in the kernel. I do not believe it is. Now, with a microkernel, things are a bit different because there is a much more vague line between what is and isn't the kernel so there may be room for arguement there, but for the standard monolithic kernel, high level code just has to much overhead to be effective.
But either way, I don't think any "tradeoff" that sacrifices correctness for speed is really a "tradeoff", it's just a mistake.
What is truely needed is a mechanism to perform allocation/deallocation during compile time instead of run time. A mechanism to determine when a pointer is no longer valid and then inserts a deallocation within the code at that point. Solving poor programming during run-time is just a bad idea.
int func(int a);
func((b += 3, b));
Again, I'm not really suggesting a garbage collector in the kernel, nor trying to write a monolithic kernel in a high level language. I think both would be possible, but they don't fit into the model that's currently used in, say, linux. I basically agree with what you're saying.
Is it really true that malloc and free are not used in the kernel? I thought there was like kmalloc and kfree that acted just like those, and I would assume they are implemented in a similar way. I don't know, I've never actually worked on the linux kernel, but when I did my own kernel in school I had stuff like that.
>> But either way, I don't think any "tradeoff" that sacrifices correctness for speed is
>> really a "tradeoff", it's just a mistake.
>
> What is truely needed is a mechanism to perform allocation/deallocation during compile
> time instead of run time. A mechanism to determine when a pointer is no longer valid
> and then inserts a deallocation within the code at that point. Solving poor programming
> during run-time is just a bad idea.
Garbage collection doesn't solve "poor programming"; it's a feature that a language offers that makes it easier to write programs. Of course, you can write poor programs in a language with any set of features.
But, a mechanism that is as you describe is "regions". You might read about that; it's a totally compile-time memory allocation inference scheme. (Unfortunately it is somewhat less flexible than garbage collection, but it does perform well.)
Is it really true that malloc and free are not used in the kernel? I thought there was like kmalloc and kfree that acted just like those, and I would assume they are implemented in a similar way. I don't know, I've never actually worked on the linux kernel, but when I did my own kernel in school I had stuff like that.
kmalloc/kfree are much like their malloc/free counter parts. kmalloc/kfree return pointers to logical kernel memory. Logical kernel memory is usually directly accessable but not always. It usually corresponds directly to hardware memory (usually differing only by an offset). There are other functions (vmalloc, etc.) that return virtual kernel memory which is more like the memory returned by malloc. Virtual memory cannot usually be accessed directly.
The memory model in the kernel is much different in that it allows both fragmented allocation and page allocation. O'Reilly has a great book Linux Device Drivers that is actually under the GNU FDL and is available online at O'Reilly's homepage. There is a chapter devoted to kernel memory in it.
Garbage collection doesn't solve "poor programming"; it's a feature that a language offers that makes it easier to write programs. Of course, you can write poor programs in a language with any set of features.
If good programmers weren't penalized by it, then I would full heartily support garbage collection. Languages should not sacrifice in order to support user-error. The fact that it doesn't eliminate error only helps my point. Take the following:
In Java:
{
String a = new String("test");
String b = new String("test2");
a = b;
}
In C++:
{
String a = "test";
String b = "test2";
a = b;
}
Neither piece of code has a memory leak. Used properly, C++ is just as easy to use as Java. You have to _try_ and leak memory in C++, it doesn't happen automatically. Java prevents this by penalizing good programmers. That's my problem with it.
int func(int a);
func((b += 3, b));
Much more important is correctness, and as we see time and time again, even "good programmers" make mistakes that can sometimes be devastating.
I don't think you see my point. Most objects simply belong on the stack. That doesn't happen in Java. In fact, that is exactly why there is a stack, to provide automatic memory management.
As for a tree example, that's what containers are for. One can build a tree in C++ without ever calling an allocation function.
It is possible to prevent new from being called on an object, and it is also possible to disable the global new. A programmer could conceivably disable these things and thereby never have to worry about memory leaks. Allocating dynamic memory is not always the answer and is much, much slower than just using the heap.
My point is not just that C++ is good for good programmers, but a good C++ architecture can prevent bad programmers from doing bad things. The only difference between C++ and other high level languages is that it gives you the option to do dangerous things. It's really a matter of programmers not knowing their limitations.
Heap compaction is not nearly that important unless there is a great deal of allocation. For most long running programs, allocation is rarely continuous. Usually, it is periodic, in which, heap compaction does very little.
int func(int a);
func((b += 3, b));
> I don't think you see my point. Most objects simply belong on the stack. That doesn't
> happen in Java. In fact, that is exactly why there is a stack, to provide automatic memory
> management.
Well, unfortunately Java has pretty dumb implementations. Some of my favorite implementations of garbage-collected languages like SML can allocate on the stack, and often do.
> Allocating dynamic memory is not always the answer and is much, much slower than just
> using the heap.
What is the difference between "allocating dynamic memory" and "using the heap"? You mean the stack, right? (Otherwise I am confused..)
> Heap compaction is not nearly that important unless there is a great deal of allocation.
> For most long running programs, allocation is rarely continuous. Usually, it is periodic,
> in which, heap compaction does very little.
I'd be interested in hearing your reasoning behind this. I believe that heap compaction helps especially in cases of long running programs that do infrequent allocation but have long-lived data (the common case for long-running programs). A garbage collector can reclaim fragmented space in the heap that would be impossible to reclaim through standard uses of malloc. This reduces the working set and increases locality (for caches) which are of course good for performance.
I'd be interested in hearing your reasoning behind this. I believe that heap compaction helps especially in cases of long running programs that do infrequent allocation but have long-lived data (the common case for long-running programs).
In practice, that data is usually either large quanities of initialization data though. Or, it's a bunch of small allocations that are likely continuous.
Most long running programs are daemons, and essentially start up, initialize data, and then enter a repeative state loop. There isn't really that much fragmentation in the initial data so compaction doesn't really buy much.
Compaction is only useful when a program is generally allocating small bits of memory where most - but not all of it - is freed after being used. Most programmers go to great lengths to avoid frequent allocations so this is why this behavior does occur frequently.
Now, in a language like Java where memory is allocated far more often then it should, you run in to a circumstance where compaction is required.
int func(int a);
func((b += 3, b));
libglib can be compiled with rudamentary mem checking. (See g_mem_profile and g_mem_check).I've also found that using glib sometimes makes memprof much happier than malloc/free. Memprof does not like openssl though!
Pan
I said no... but I missed and it came out yes.
My macro works fine thanks. Yes, I am aware of ways in which it will not work but c'est la vie.
My main concern is instances of the following.
buf = malloc(BUFLEN);
do stuff..
if (!x) FREE(buf);
if(buf) {
blah;
FREE(buf);
}
Pan
I said no... but I missed and it came out yes.