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.
473 comments
more info please
by
Sebastopol
·
· Score: 2, Informative
could somebody point out where in the source this is? the article was fluff.
The bug has been discovered announced and soon (already?) fixed. Because the system is wide open and everybody knows how it works there are no problems reguarding not knowing exactly what is going on. Any fixs that are released will be actual fixs and not just fluff or cheezy workarounds that will soon be broken again.
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.)
> Um...because that's the way nearly every package that uses zlib links it?
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.
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
Re:Linux only?
by
Anonymous Coward
·
· Score: 1, Informative
it's probably one of the most prevalent libraries around, it's even on my handheld for plucker, the palm-based offline browser; webservers or proxy accelerators using gzip compression could even be at risk.
The article says this is only affecting Linux
by
Chloe+Dubois
·
· Score: 1
But will this affect other systemes using the zlib, such as FreeBSD or many open-sourced Windows softwares? This article is near empty of useful information. If a security-minded person is out there, please give us Slashdotters more information so we can protect our systemes!:-/
-- Sincerely yours,
Chloë
Re:The article says this is only affecting Linux
by
Ooblek
·
· Score: 0, Troll
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. Maybe the fact that Redhat found it lead the press to bridge the conclusion that it was a Linux only issue.
For all Window's flaws, it just shows that no one is above releasing buggy software. It happens.
Re:The article says this is only affecting Linux
by
Anonymous Coward
·
· Score: 0
The recent PHP4 buffer overlfow bugs only affected Linux and Solaris, so it is not simply a case of "one bug fits all". I am not saying FreeBSD is in the clear (my OS of choice!) but it needs checking out.
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.
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?'"---
Re:The article says this is only affecting Linux
by
HMC+CS+Major
·
· Score: 1
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:The article says this is only affecting Linux
by
mirabilos
·
· Score: 1
For windows, as for any other OS, it depends on free() which is usually a libc function. Except for mingw32 and very old MS C versions, the compiler is the library vendor, and so it depends on the compiler you are using whether the bug is active or not. (It is still in, though.)
Darn 2 Minute posting limit! Why don't people simply read the comments?
-- My Karma isn't excellent, damn it! (And/. still does not get UTF-8 right in 2012. Wow.)
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.
More information from CERN Later today
by
Mr.Intel
·
· Score: 0
From the article: " The Computer Emergency Response Team (CERT) Coordination Center at Carnegie Mellon University is expected to release more information Monday afternoon"
It also says they "could not be reached for comment".
-- ASCII tastes bad dude.
Binary it is then.
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
Anonymous Coward
·
· Score: 0
yup and programs like memprof take that a step further and actually run the prog looking for problems
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.:)
-- "Old man yells at systemd"
Re:Dumb security question
by
jfonseca
·
· Score: 1
There isn't a C virtual machine (that I know of), though.
Hi, I think I understood what you tried to say, but can you tell me of one machine these days that is not a virtual machine for C?
Gone are the days when your C program touched the machine at all!!!
-- Broken Hearts are for Assholes. - Frank Zappa
Re:Dumb security question
by
Anonymous Coward
·
· Score: 0
Thus spoke the java programmer who is to blind to see the failings of his language. I am sorry but it will be a cold day in hell before I sacrafice speed in critical programs (web services for high traffic sites, enterprise application servers and so forth) just so someone can be lazy and use a "safe" language. C is fast. Thats what it does. It actually requires a good programmer to program in it since its not safe, but thats the sacrifice you have to make.
If java was really so cool then how come no jvm is written in it.
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
dwheeler
·
· Score: 1
YES. It's definitely possible to use tools
to search through code and find problem areas.
Such tools are called "source code scanners."
There are at least two open source software/
free software source code scanners that
work like this. My tool
Flawfinder
does this, as does John Viega's
RATS
tool. Both tools are licensed under the GPL.
They both work essentially the same way;
they use patterns and some heuristics to
identify "dangerous" function calls and patterns,
and also try to rank their riskiness.
They both have built-in databases
(so you don't have to figure out what should
be looked for), and they both parse the code
sufficiently so that comments and data in
strings are ignored.
They also examine the parameter values to
determine the riskiness of the construct.
Both were influenced, by the way, by a previous
tool called ITS4.
Eventually we hope to merge our efforts, but it
hasn't been immediately obvious how to do so.
In fact, it can be argued that we shouldn't: having two tools is like having two different people look at something, each catches or emphasizes something the other doesn't.
I think running either
tool on the entire distribution would result
in too much output to be
worthwhile. These tools simply identify
potentially dangerous code - you still have to
look at the code to determine if it's really a problem.
My hope, instead, is to convince the various
developers of each package to use such tools
to find potential problems before the
code is released to the public.
Don't let me discourage you from trying -
please do review what you can!!
But I'd like to see everyone reviewing
code they work with, not just a few
code reviewers.
I'm a big believer in defense-in-depth
strategies.
You should use source code scanning
tools like these to find problems
in your code before you run it.
You should then run tools like Purify and
Electric Fence to find other problems.
Then, use tools and mechanisms that counter
security attacks at run-time, e.g.,
StackGuard, TempGuard, and so on.
It would be great if there were a global
setting so that you could make ALL
programs use the "slow but safe free()"
without having to recompile the C library.
Re:Dumb security question
by
Anonymous Coward
·
· Score: 0
Oh, boy.
Okay, *you* use a freaking slow Java implementation of zlib. Hint: divide your computer's clock rate by 5, and you should get a pretty good idea of your performance hit.
*I* like having lots of utilities that transparently and efficiently decompress data just while I'm working with it (man pages, log files, etc).
All these idiots screaming about C sucking are completely wrong.
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.
Re:Dumb security question
by
Anonymous Coward
·
· Score: 0
oh, for fuck's sake, get another fucking hobby horse to ride.
Leave us alone. You can write crap code in any language. C is the best language we have right now for many things. (anything that has to run a bit faster that "shit on a stick")
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
Anonymous Coward
·
· Score: 0
For god's sake don't give anyone any ideas...
Re:Dumb security question
by
Anonymous Coward
·
· Score: 0
"it actually requires a good programmer to program in it since its not safe, but thats the sacrifice you have to make. "
Well then i guess you are implying no open source (OR closed source for that matter) programmers are good. Because just about every OS and daemon has had vulnerabilities, lot's of vulnerabities.
Apache is probably the only daemon on unix that hasn't been hit by buffer overflows at one time or another. Well it stillhas them probebly but since it doesn't run as root there's not much you can do with them.
Anyways, it's pretty sad when people declare the C the end of progress in languages.
Talk about scared of change and/or lacking imagination.
Yes computing peaked in 1969 with the creation of UNICS and C....
yick.
Re:Dumb security question
by
Kunta+Kinte
·
· Score: 1
A static checker will find most of those errors, including sometimes range issues like the last OpenSSH hole.
If you're interested in static analysis...
http://www.cs.berkeley.edu/~weimer/osq/
http://suif.stanford.edu/
http://www.research.ibm.com/people/h/hind/
Well, the problem is undecidable in general (of course), but it's certainly possible to do some static analysis to find bugs.
Much easier would be to simply write code in a modern language that is immune to these kinds of bugs. There's nothing so low-level about zlib that it couldn't be written in a high level language.
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?
Re:Dumb security question
by
|<amikaze
·
· Score: 1
*chomp* i'll bite.
Have you ever seen a Visual Basic program crash? Or run slowly?
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.
--
~shiny WILL HACK FOR $$$
Re:Dumb security question
by
leviramsey
·
· Score: 1
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?
Uh, assert is part of the C library
From/usr/include/assert.h:
/* Copyright (C) 1991,1992,1994-1999,2000,2001 Free Software Foundation, Inc.
This file is part of the GNU C Library. . . . /*
* ISO C99 Standard: 7.2 Diagnostics
*/
Assertions overall are a good thing... at the very least they allow a measure of self-documentation. Your argument applies to any debugging, or sanity checking code...
I believe a number of commercial lint programs exist which check for bad assertions.
Re:Dumb security question
by
leviramsey
·
· Score: 1
Another possibility is to build and run the program under a virtual machine which checks these things
I may be misinterpreting your post, but there are a couple of debugging versions of the C libraries that do check for all sorts of memory errors (and others...)
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.
And very useful when writing a TSR. I recall my first experience with C involved my exclaiming, "What the f*ck! This compiler complains about accessing the interupt vector????" I used more colorful language though. All this 'C is evil' talk just has me scratching my head. C lets me write less assembler, I like that.
It's not that I'm in the stone age, while I hate Ada & ML I use Java whenever I can. Computers are about 2^42 times slower that I'd like them to be. I'm pretty sure I'll say the same thing in 10 yrs too.
Re:Dumb security question
by
ironfroggy
·
· Score: 1
yea but then we still gotta program the compiler for that in probably C/C++ and assembly for the first versions and im sure someone would stick zlib in there somewhere!
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.
SML is a functional programming language, not a logic programming language.
While it would be nice, I afraid the general case of the question you want to answer (if memory is freed etc.) is undecideable, being easily reducible to the Halting Problem.
Of cause special cases can be decided, and any tool which does so would be great. But it is definately non-trivial to write for interesting cases.
So your second option, review/audit is a much better solution.
Re:Dumb security question
by
Anonymous Coward
·
· Score: 0
Yes computing peaked in 1969 with the creation of UNICS and C....
*shrug* It could be worse. We could have peaked in 1960 with TOPS-20 and Algol.
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.
Version 1.1.4 fixes the problem
by
Kutsal
·
· Score: 0, Informative
(BTW: The 'c' in your link was unnecessary and www.zlib.org resolved to www.gzip.org/zlib)
-- Withdrawal before climax is very ineffective and those who try this are usually called "parents."
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.
Doesn't proftpd do zlib like wuftpd does? And are those the ONLY things that EVER run on that box? I wouldn't rely on just that to save you. Even if it isn't a network service that uses zLib, it is still dangerous (priviledge escallation, etc).
--
----
All of whose base are belong to the what-now?
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.
Re:Did this get released early?
by
irix
·
· Score: 1
Ah, I see that zlib.org just got updated - never mind. When I got the email from RedHat this morning there was nothing else available yet!
--
Do you even know anything about perl? -- AC Replying to Tom Christiansen post.
Re:Did this get released early?
by
Mr.Intel
·
· Score: 1
See the gzip advisory here. And get the 1.1.4 binaries here.
-- ASCII tastes bad dude.
Binary it is then.
Re:So much for "many eyes"....
by
DaveJay
·
· Score: 1
Impossible? Not at all -- only a foolish person would claim such a thing, and I don't believe that any respectable member of the community would claim it.
Less likely to occur? Arguably. I won't start that discussion.
Fixed more quickly? I guess we'll find out soon enough.
Re:Hilarious
by
Anonymous Coward
·
· Score: 0
Anyone who reads this site.
Your post will never get modded up as insightful. That's just wrong.
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
DarkAurora
·
· Score: 0
Statically linked:
The library object code is merged into the program that you compiled.
Dynamically Linked (shared):
The library object code is kept seperate (in/lib,/usr/lib, etc.) and the program is compiled to ask a dynamic linker application (ld on linux) for the code whenever the program comes to that spot in the program.
Re:Staticly linked-implication
by
jezcope
·
· Score: 1, Informative
Try using the ldd command, which prints dynamic library dependencies. Something along the lines of
find/usr/bin | xargs ldd
should give you something to grep through, although because of the way ldd formats it's output, you might need something a bit more intelligent to find exactly what you want (i.e. a list of files linked against libz). I'm not a perl guru, but i don't think it would take too long to knock together a suitable script.
-- Fabricate diem, punc
Re:Staticly linked-implication
by
Anonymous Coward
·
· Score: 0
Did you even read his question? He said statically linked. I'll leave it up to you
to find out what that means.
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
Anonymous Coward
·
· Score: 0
um, you'll be waiting a looongggg time for that to finish.
you want:
grep -e '-lz' so forth
Re:Staticly linked-implication
by
cicadia
·
· Score: 1
Whoops - you're right. I actually ran grep 'lz' and just added the '-' to the comment above when I realised that I was getting a couple of false matches.
Should have tested the new command (or read the man page) first. Thx
--
Living better through chemicals
Re:Staticly linked-implication
by
mirabilos
·
· Score: 1
Why went the GNU/Linux community to the Windows equivalent of the DLL hell and distributing binaries? OT, but nevertheless interesting.
-- My Karma isn't excellent, damn it! (And/. still does not get UTF-8 right in 2012. Wow.)
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.
Re:No buffer overflow!
by
Anonymous Coward
·
· Score: 0
In fact, I have _never_ seen a duplicate deletion exploitation other than a simple DoS.
Whew! That was a close one. I mean, as long as you have never seen one, then it can't happen. Wow, why didn't they just ask you in the first place, instead of causing all this commotion? For Christ's sakes man, give them you e-mail address so this doesn't happen again!
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.
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.
Version 1.1.4 fixes the problem - correct link..
by
Kutsal
·
· Score: 1
Sorry for the earlier Freudian slip.. The website is at http://www.zlib.org and they have just updated their website and it's not/.'ed.. Yet...
Sorry for the earlier wrong link..
-- Karma: Bad (but who really cares anyway?)
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.
Re:Closed source projects that statically link
by
mirabilos
·
· Score: 1
It depends on the target platform's malloc implementation (free, to be exact). OTOH you are correct.
-- My Karma isn't excellent, damn it! (And/. still does not get UTF-8 right in 2012. Wow.)
Thank you for the reply
by
Chloe+Dubois
·
· Score: 1
I am not worrying about Windows so much as I am my FreeBSD and OpenBSD boxes; I assume they all utilise the same zlib functions, and thus would possibly be open to attaque as well. I only ask of Windows because I know many Windows softwares (such as Mozilla) use the zlib as well.
-- Sincerely yours,
Chloë
Re:Thank you for the reply
by
Anonymous Coward
·
· Score: 0
Read the above comment which states that it's really excaberated by a glibc problem, which makes it a far worse bug on Linux than any of the other Freenixes.
Re:And why...
by
Anonymous Coward
·
· Score: 0
Aren't you supposed to say - First Anti-Microsoft Post before you type anything else?
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
Anonymous Coward
·
· Score: 0
You're most likely right. There isn't exactly any other feasible reason to -remove- GZIP encoding, unless there was something wrong with their own, specific implementation of it. But somehow I doubt that Microsoft is too concerned with whose implementation of anything that they use..
Re:I was just thinking about this earlier today...
by
Anonymous Coward
·
· Score: 0
No, they simply removed gzip encoding because it's an open standard, and they don't like open standards.
Also, zlib on windows wouldn't be exploitable, because double-frees on windows won't screw up like on linux.
Re:I was just thinking about this earlier today...
by
Mr+Z
·
· Score: 1
Also, zlib on windows wouldn't be exploitable, because double-frees on windows won't screw up like on linux.
Care to explain your reasoning behind that one?
Calling free() twice on the same pointer
typically is bad news. (Actually, some old
malloc implementations tolerated
certain forms of double-free from what I recall.) ZLib doesn't call free() directly, but rather relies on you to register a "ZMalloc" and "ZFree" hander that interface to your applications/environment's memory handler (usually, these call malloc and free, but aren't required to. In fact,
in places like the kernel, you must call something else -- kmalloc or vmalloc for instance.) Depending on how ZLib is integrated
with the rest of the app, a given program may
or may not be vulnerable to this particular
problem.
So how does that translate into "Linux is
vulnerable and Windows is not?" If both are
using ZLib, and vulnerability is tied to
ZLib and how it's integrated with the app,
then I think we can agree that OS doesn't
matter.
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
Anonymous Coward
·
· Score: 0
But decoding (99.999999% of the time) is still in there?
The only way they would be using gzip encoding is to send data via xmlhttp in msxml3sp2. I don't think you ever got to specify whether it was gzipped or not.
...Rodney
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
Anonymous Coward
·
· Score: 0
RedHat provides updates of the 2.2.x kernel for RedHat 6.2/7.0 series, but no update for the 2.4.x kernel for RedHat 7.1/7.2, so I'm guessing that 2.4.x kernels are either uneffected or had this problem fixed a lot earlier.
Likai Liu
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?
I think that if open source projects actually had the same amount of usage as closed source projects (read: linux software had the same amount of usage as windows software) there'd be a fairly even amount of bugs found. Just guessing.
Though it's definitely obvious that open source software that was used that much would also have fixes available for it a lot faster than closed source. Then you would think that over time, open source software would be much more bug free, but it would be advancing faster from all the time not taken up by bugs, therefore introducing more bugs again.
THEN you'd get all those open source developers wondering why they weren't getting paid for their hours and hours of work.....:P
Re:ouch
by
Anonymous Coward
·
· Score: 0
linux, freebsd, whatever.:P I don't care about clumping them together for this.
------ Wish I wasn't so lazy that I don't want to go retrieve my/. password. NeuralizR
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?
I don't follow you. Because someone found a bug that means there aren't enough eyes to find the bugs? Most of the eyes aren't involved with the project, they're "out there" in the rest of the community.
--
--
As a matter of fact, I am a lawyer. But I play an actor on TV.
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.
All of whom were stamped out within hours of being found.
That's the strength of open source.
I believe this is more correctly stated:
"...stamped out with hours of being released"
Not every person who finds a bug immediately tells the open source community.
I don't think there are that many more, I just think they're much more publicized. Now I'm not a MS conspiracy freak, but.... it does help them a bit. Of course, it also helps us that the open source bugs are quickly fixed...
--
jred
I'm not a mechanic but I play one in my garage...
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...
"I don't follow you. Because someone found a bug that means there aren't enough eyes to find the bugs? Most of the eyes aren't involved with the project, they're "out there" in the rest of the community."
I've been using FS/OSS since '94-5. It seems to me that there are many more security problems being discovered now then there were back then, and they affect some of the basic building blocks of the FS/OSS world.
What I was asking is if FS/OSS is getting more eyes on the code (e.g. more people spotting bugs) due to it's wider support & deployment now versus then.
Re:ouch
by
Anonymous Coward
·
· Score: 0
Most Microsoft bugs are stomped out damn quick as well. Then they go and make a patch that is easy to deploy, something that usually doesn't happed with open source. That way the fix will actually be deployed on a wide scale. Such is the strength of a large corperation with unlimited resources.
"...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.
Re:ouch
by
Anonymous Coward
·
· Score: 0
Code audits are a good thing, but if you're suggesting that even code audits can detect 100% of software bugs (particularly obscure memory errors) then you are either woefully obtuse or being deliberately hateful towards Linux. In the case of the former, consider yourself corrected. In the case of the latter, consider yourself ejected. Go to your precious *BSD; we neither want nor need you.
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'
Re:ouch
by
Anonymous Coward
·
· Score: 0
a large corperation with unlimited resources
Really? So they can, say, move the Earth's orbit or cure cancer?
> 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...
No, it means the clueless remain just as vulnerable to mistakes by the vendor when the updates break something else. Clueless is clueless, and helpless as well.
How vague can one question get. There's piles of open source software. Huge piles. And "quality" is about as uselessly nonspecific as one can get. And has anybody measured it? This is a complete "how do i feel right now" question, which is influenced by the article, slashdot, and the burrito you ate for lunch.
Agreed...same for open source as well though I would have to believe. Someone who is running an open source project and adding patches as often as they are released would be doing the same with a closed source project. Both projects are succeptible here...the best they can do is hope the user installs the patches or uses some auto-update program feature
Re:ouch
by
Anonymous Coward
·
· Score: 0
This is true. What is also true is that complexity breeds bugs in spades. Linux is becoming more and more complex every year. The bug rate will surely keep climbing. As software becomes more complex even more attention to bugs and security issues must be paid, but unfortunately (Like on Windows) complex code and complex interactions between code modules take so much more time in the writing that people spend even less time making sure they are safe.
Complexity goes up, demands get higher, time to market shrinks. Not good for the development of "safe" and "Secure" software. I guess it's a sign that Linux is growing up to be feeling such pressures to release all those buggy 2.4.x kernels and ancillary programs. After all, who is actually testing all those releases? That's right. The users. If this keeps up Linux could well outstrip windows and for bugs in no time. O.S. projects need to go though a closed door beta program to get people to hammer on the code before it's released to the public at large. Then you at least have a chance of releasing error free code. As it is, there is no chance at all.
Re:ouch
by
Anonymous Coward
·
· Score: 0
Nice comback. Completely ignore the sentiment and make an obviously out of context comparison. You might at least learn how to argue before opening your mouth here...
Re:ouch
by
Anonymous Coward
·
· Score: 0
This got voted a 5? Interesting, my ass.
But I digress. If you want a constant stream of bug reports, go look at the ones dealing with Internet Explorer.
Correction: Updated source code was made available within hours of being found. While it's far superior to the Microsoft solution (beg and beg for us to put a fix in the next Service Pack and we just might). But don't forget that there are lots of folks who won't be made aware of the hole, or won't bother plugging it. A lot of people will end up leaving it open until the next distro upgrade. As for me, I'm probably going to upgrade the.so and then flush it from my brain forever.
To say it was "stamped out" is an exaggeration.
--
You want the truthiness? You can't handle the truthiness!
What is horrible is not having armies of college students coding, but having armies of lousy "farmers" who won't even bother patching their systems running all those servers.
No one is perfect, and no one human can code perfect software, and it is not reasonable to expect it, there will always be bugs, live with it, people.
What I was asking is if FS/OSS is getting more eyes on the code (e.g. more people spotting bugs) due to it's wider support & deployment now
Sorry for the delayed reply. Somehow I read just the opposite in your post. The snippet I quoted above is pretty much what my thoughts are. Things that slipped by in the past are being caught because of expanding community and also due to the cross-pollination that takes place when a piece of code from one project is appropriated for duty in another. Now a new set of programmers are looking at your code because they want to make sure it won't cause problems with their own project when it's folded in. Another factor may be that a new generation of programmers come aboard a project and free up some of the time for more experienced heads to review what's already out there.
--
--
As a matter of fact, I am a lawyer. But I play an actor on TV.
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
Anonymous Coward
·
· Score: 0
I didn't realize that the new Slashdot advertisements would come in the form of anonymous posts also. I wonder how much Webstar paid for this one.
Re:zlib rarely used in MacOS. MacOS safe.
by
maeglin
·
· Score: 1
No one has yet to be able to hack into my ethernet enabled brick either.. It was difficult to make (what with drilling the hole and trying to mash the UTP end into it) but it was well worth it for the security!
Re:zlib rarely used in MacOS. MacOS safe.
by
Anonymous Coward
·
· Score: 0
I wonder how much Webstar paid for this one.
Not much... if you pay more then you get to post your ad at +1 or +2;
Re:zlib rarely used in MacOS. MacOS safe.
by
Account+10
·
· Score: 1
p=malloc(somesize);
free(p);
free(p);
Do mac apps crash or not?
That's all that's relevent to this discussion.
Re:zlib rarely used in MacOS. MacOS safe.
by
Anonymous Coward
·
· Score: 0
no... deleting two HEAPS on a mac can crash, or closing two times on sdame file (in older os), but not delete twice.
why?
Because the mac programmers do not use ANSI C lib usually and instead use apple memory manager.
Apples memory manager does not have this defect.
Re:zlib rarely used in MacOS. MacOS safe.
by
Anonymous Coward
·
· Score: 0
its not an ad!
Heck I HATE the current Webstar. If I mentioned that in the article it might not seem like an ad. I should have said PRE-2002 copies of WebStar.
Happy now?
Mac OS is more secure, the article mentions a commercial grade web server for illustrative usage.
Re:zlib rarely used in MacOS. MacOS safe.
by
Anonymous Coward
·
· Score: 0
2> No Root user.... By always being root...
So which is it smarty pants?
Re:zlib rarely used in MacOS. MacOS safe.
by
Anonymous Coward
·
· Score: 0
A big block of cement out in the middle of a field is both rock steady and reliable.
And only slightly less useful than a Macintosh.
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
Anonymous Coward
·
· Score: 0
You do not know much about the macOS
deleting twice is OK because the heap is not shared between programs, and threading is very rare in commercial mac apps.
Cooperative mac programming has hundreds of rules more sophisticated than 1972 style UNIX programming.
deleting a memory object twice is safe and part of the mac design.
deleting a heap twice can corrup tthe memory though.
you are wrong about free()
plus mac engineers do not use ANSI C libraries usually
Re:zlib rarely used in MacOS. MacOS safe.
by
Anonymous Coward
·
· Score: 0
Fuck you. I am no troll, trolls give a shit if people respond. I wish I could post with a "no remarks desired attached to this post" feature because I am not a troll. And I do not give a shit what you think of my posts.
That proves I am not a troll.
Why dont you read the definition of a troll on a FAQ site somewhere?
people who try to teach you how stupid you are are not trolls.
Provocative words are not trolls.
In fact I would say YOU are the fu*king troll.
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:zlib rarely used in MacOS. MacOS safe.
by
Anonymous Coward
·
· Score: 0
Your agrument about the change a single number shows you have no knowledge on pascal type strings.
They are vastly better for most applications IMHO. Not all, but most.
Re:zlib rarely used in MacOS. MacOS safe.
by
Anonymous Coward
·
· Score: 0
> 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!
There are two things at work here. Windows has exploits for one reason, and Unix for another; for the Mac, neither is applicable.
1. Macs don't have the exploits Windows has
mostly because they are less prevalent.
Windows is worth exploiting mainly because
if you once develop a single exploit, you
can garner control of a few thousand
systems virtually overnight. This does
not apply to the Mac. However, it doesn't
apply to VMS either... but there are VMS
exploits. Hence the second point...
2. Macs don't have the exploits Unix and VMS
and so on have because (until very recently)
they were a less attractive target. If you
have a compromised Unix box at your disposal,
you have lots of powerful tools. If you
have a compromised pre-X Mac at your disposal,
you have to install programs to do anything
you should happen to want to do. (This is
also true for Windows, except NT, but there
are enough millions of THOSE out there to
make it worth doing anyway.) Besides
that, Unix and VMS boxes tend to be well
connected and have a lot of resources, in
terms of CPU power, memory, drive space for
storing things, and so on. Except for a
relatively few G4s, Macs tend to have
nothing of the kind.
There are, however, oodles of file viruses for the Mac. The motivation for writing a file virus is different from the motivation for creating a remote exploit.
Re:Programming languages: fool me once ...
by
Anonymous Coward
·
· Score: 0
cool. i task you with rewriting all of linux in modula-3. see ya in a couple of years.
Better to hear of a buq then to be exploited.
by
Quazion
·
· Score: 1
I always wonder when a nice buq comes around how long it will take before i get exploited and darn i get exploited, but then i can only blame my self for not upgrading.
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.
The patch is already out. The thing that really sucks is how many packages use a statically compiled version of zlib. I now have to upgrade 22 seperate packages on my Redhat 7.2 box. Fun fun fun...
--
This sig has been temporarily disconnected or is no longer in service
Am I paranoing or what?
by
Anonymous Coward
·
· Score: 0
Why do I think that this headline smells like one step in an orchestrated machievical plot of FUD?
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/* ?
On my system, I pre-empted this into the valid shells with shell-specific methods (alias for/bin/sh,/etc/profile for bash, etc) and since I have a small pid tracking library script in my startups, I was able to set the variable there as well.
This leaves some random daemons whose startup scripts are automatically installed and aren't aware of my startup library, and use scripts that aren't valid shells or actual binaries directly, or adding a shell to the init file corresponding to it.
On my system there were only a few of these, so I replaced the binaries/scripts with two-line bash scripts that simply executed the original file.
Hum. I suppose you could write a exec* wrapper that inserts the environment variable always. That could definitely be system-wide, always, but then we're leaving the realm of 'Easy'. Well, maybe not. It wouldn't take so many lines, but you'd have to mess around with library symbols and stuff.
Also, cron jobs! Same problem... Although these are much less likely to get arbitrary, malicious input.
I really meant "Easier than recompiling everything statically linked on my system right now in case someone figures out an exploit", rather than 'Easy' in a one-liner sense, I guess.:/
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.
Why didn't they use 'purify' ?
by
Lord+Hugh+Toppingham
·
· Score: 1, Informative
Surely this kind of problem could be easily avoided if the developers had used 'purify' to check for memory leaks. Or are the open-sourcers too high and mighty to use 'proprietary' software even when it would improve the quality of their code ?
Re:Why didn't they use 'purify' ?
by
Anonymous Coward
·
· Score: 0
you wanna buy purify licenses for every open source developer doing this in their spare time? I thought not.
Re:Why didn't they use 'purify' ?
by
Anonymous Coward
·
· Score: 0
It's not a memory leak. They plugged a memory leak twice by accident.
Re:Why didn't they use 'purify' ?
by
Anonymous Coward
·
· Score: 0
Purify would still fix this.
Plus, you don't need it for everybody, just the person doing the final release candidate.
My guess is that this is more of a philosophical thing than a technical thing.
Re:Why didn't they use 'purify' ?
by
Anonymous Coward
·
· Score: 0
Well, then, enjoy the dirt floor in your hut, out in the village by the bazaar, peasants.
Re:Why didn't they use 'purify' ?
by
Anonymous Coward
·
· Score: 0
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:One more bug OpenSSH is affected by...
by
mirabilos
·
· Score: 1
Or fix GNU malloc in your libc. OpenSSH links dynamically against free(), doesn't it?
-- My Karma isn't excellent, damn it! (And/. still does not get UTF-8 right in 2012. Wow.)
Women like men who can communicate.
by
Anonymous Coward
·
· Score: 0
On another topic:
The ad at the top of the page says, "Chicks dig case mods." Is there any wonder why VA software doesn't make money?
Re:Women like men who can communicate.
by
Anonymous Coward
·
· Score: 0
Chicks that dig case mods and stickers on japped out cars also like shiny objects and have been known to be run down by cars that have their highlights on when crossing the street, film at 11.
Selective, are we?
by
Renraku
·
· Score: 1, Offtopic
-- Job? I don't have time to get a job! Who will sit around and bitch about being broke and unemployed then?
Re:So much for "many eyes"....
by
carlos_benj
·
· Score: 1
Funny, wan't this supposed to be impossible under Open Source?
Yes, it is impossible to introduce a bug in Linux code. It just can't happen.
I'd say this is more a demonstration of the "many eyes" principle at work (unless the RedHat employee who reported it has no eyes).
Seriously, it looks like maybe it isn't so simple. In the "golden days" a lot of companies bought into the idea that Open Source code was free from these types of major flaws... now they see this isn't true.
Still waiting for the "serious" part here. I don't know of a consensus among companies that postulated that view at any point in Linux history.
So, when the glow is off the rose we see that Linux is no more reliable (thanks to 4.2) and no more secure than a well maintained Windows 2000/XP system.
I don't think you're taking the glow off the rose as much as shaking the dew from the lilly here.
Fight tyranny and repression.... read/. at -1!
If this was an indication of your well reasoned response, that's the only way your posts will be read then. Don't mistake tasteful discretion for tyrannical repression, it'll only make you paranoid.
--
--
As a matter of fact, I am a lawyer. But I play an actor on TV.
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
mirabilos
·
· Score: 1
Yup, thanks for the pointer, OpenBSD-current is definitively not affected. On the other hand, it _is_ a problem in libz, yeah, really, a bug, which can only let the program crash under glibc (I wonder if libc5 is affected). It does affect execution of programmes on OpenBSD though: an error message is written to fd 2. This can screw up UI programmes.
-- My Karma isn't excellent, damn it! (And/. still does not get UTF-8 right in 2012. Wow.)
Re:It's not a problem in zlib per se
by
dtrombley
·
· Score: 1
No, of course one bias is never always correct! It's especially difficult to say for something like the ?alloc/free calls, which have potential security implications as well as consuming a significant amount of most programs' time.
I just wanted to point out that the bias was there.
Re:It's not a problem in zlib per se
by
egoots
·
· Score: 1
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;
Not quite right on Windows... only in debug mode builds with switches set will you get any kind of warning. Release mode builds will give you an Application Error.
Re:It's not a problem in zlib per se
by
Anonymous Coward
·
· Score: 1, Informative
So, you should download the patched zlib, but you should also email the glibc maintainers
Utter nonsense - the standard regarding C is quite clear and free()'ing a pointer twice is a bug; the behaviour undefined; end of story.
Trying to load off flaws onto others is not insightful but unproffesional and does not solve problems in the real world.
Re:It's not a problem in zlib per se
by
Idolatre
·
· Score: 1
That's nice, but does the kernel (which uses zlib) have access to environment variables?
Re:It's not a problem in zlib per se
by
Anonymous Coward
·
· Score: 0
> MALLOC_CHECK [123] > OK, now what exactly can people put in their rc.local? Btw., anybody know where to find rc.local on Suse 7.3?
Re:It's not a problem in zlib per se
by
Anonymous Coward
·
· Score: 0
What's this? Windows is much more secure and intelligently written than linux? Well I never. Free software is only free because it's too bloody terrible to sell.
Go back to Microsoft, you silly 'l33t' zealots, linux has absolutely no place on the desktop. Nor, it seems, on servers.
Re:It's not a problem in zlib per se
by
Anonymous Coward
·
· Score: 0
> OK, so what exactly do people put in their rc.local? > And how would one find out what other apps might use the statically compiled in zlib? Preferrably a package-manager independent way...Thanks!
Re:It's not a problem in zlib per se
by
Anonymous Coward
·
· Score: 0
... for something like the ?alloc/free calls...
Indeed, the bias is there. It looks like a question mark, and seems like it is in favor of M$oft...
Re:It's not a problem in zlib per se
by
Elladan
·
· Score: 1
Freeing a pointer twice in the C language is an
error. It is not allowed. It is a security error whether or not you have a heap with some debugging code in it to help you find double frees.
glibc includes double-free checking as others have pointed out - it's just not turned on be default in your average distribution.
It should be understood here that there is a reason the C language specifies a double free as an error. It does this because it is not possible to defend a program against the problems this causes unless one uses a bounds-checking C compiler (there is a GCC project in the works to create one, though of course, with a significant performance loss.)
What glibc and all the other heap implementations on other OS's provide for heap debugging is not a security-quality defense. It does *not* solve the problem and prevent all exploits. What it does is just catch some instances of it, and so reduce the probability that the bug is exploitable.
Ler me give an example. Say you're using some uber-great heap library, that can perfectly know if you're freeing a pointer from the heap.
Consider the following code:
int *a = (int*)malloc(sizeof(int)*10);
int *b;
free(a);
b = (int*)malloc(sizeof(int)*10);
free(a);
read(socket, b, sizeof(int)*10);
Note that a and b could be in completely separate parts of the program, with other calls to the heap in between.
In the example, even with a perfectly error-checking debug-mode heap, you may have just not only misused the heap, but actually caused a buffer overflow error and just had your box rooted as well.
The reason is, there is no guarantee that a does not equal b! In fact, it is not at all unlikely that it will. What happens in this case, though, is that the double free of a is, from the heap's point of view, a legal operation. If a == b, then freeing a is just freeing b. But, the application thinks that b is still valid - so it uses it. This behavior is undefined, and could easily be an exploitable buffer overrun. (BTW, don't think read is safe because it's a system call accessing unallocated memory - the memory is almost certainly still allocated from the OS's point of view)
So, even if they have this heap checking turned on, all the other OS's listed are in principle exploitable via this bug! It just might be less likely. How much less likely depends on how they handle the bug if they can catch it - if they ignore it, it's not much help at all! Of course, exploiting the bug in linux is extremely difficult to begin with, so the real difference here may not amount to much.
This is basically similar to other security hack ideas, like upward-growing stacks and non-executable stacks. Doing that sort of thing *may* prevent some exploits, but the fact that the feature exists is no *guarantee* of safety. It's just a way of reducing the likelihood somewhat.
Just because you have heap debugging turned on by default, doesn't mean you're safe from heap corruption bugs. You're not. It's just somewhat harder to exploit them - but exploiting them is extremely hard to begin with, so whether this translates into any actual security exploits for one but not the other is unknown.
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:It's not a problem in zlib per se
by
Anonymous Coward
·
· Score: 0
Regardless of how well the library is going to handle (or not...) a double free(), it's inexcusable to even attempt a double free(). I make it a point to always set a pointer to NULL immediately after free()ing it, and often use a macro to do both the free() and the NULL assignment in one "call". Anything less is just plain sloppy hacking and must not be tolerated.
Re:It's not a problem in zlib per se
by
Anonymous Coward
·
· Score: 0
So, you should download the patched zlib, but you should also email the glibc maintainers [mailto] and demand that they implement a sane, error-checking malloc()/free() system. Linux's current allocation model is a disaster waiting to happen.
It *is* a sane malloc()/free() system; from the manpage:
free() frees the memory space pointed to by ptr, which must have been returned by a previous call to malloc(), calloc() or realloc(). Otherwise, or if free(ptr) has already been called before, undefined behaviour occurs.
So, it acts *exactly* as the documentation says it will! True, I have to admit that I was thinking it would be nice to have error-checking in glibc by default, but then I realized one of the major tenets of open source: infinite options. You can already do checking if you want by using xmalloc. And maybe some people don't *want* error checking by default! Maybe some of us know what the hell we're doing when we program, or we can do our own error-checking.
I've noticed that most, if not all functions in glibc are very simple. No error checking. No allocating memory. I often wondered why this is and why they didn't make some more "helpful" functions that did more stuff. It's because they wanted to keep the core C library simple and lightweight. I can add on all the helper functions I want, or find another library that does. Someone else may not want or need them.
OFF TOPIC! LARGER ADS!
by
0xbaadf00d
·
· Score: 0, Offtopic
Oh those large ad's are so annyoing! Can I please pay so I don't have to look at them!;)
Re:Oh the IRONY!
by
WildBeast
·
· Score: 1, Flamebait
No, the previous story claimed that "Everyone seems to know... UNIX is safer than Windows". But then again, Linux is more popular than UNIX, so more bugs get discovered
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.
So how is the flaw automagically fixed for 'previous distributions', dude?
I hear all these anecdotal stories about Linux boxes shoved up on top of the filing cabinet that run for years without needing any maintenance.
I know for a fact that fixes aren't offered for older distros, i.e. older Slackware versions, etc.
There are by this time probably 10000 different discrete 'distributions' of Linux out there, if you talk about all all versions of all distributions. Many of them are set up and left going without further maintenance.
The reasoning behind your little ditty is fundamentally flawed.
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 !
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.
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.
on more than one occasion, I have seen patches for vulnerabilities discussed on CERT that are supposedly available, but NOT available on windows update.
imho, a tool that promises easy security updates like that, but fails to deliver is worse than nothing at all (by lulling you into a false sense of security).
smash
-- I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
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
You don't have to upgrade 20+ packages to fix this, unless they are statically linked. Most programs use the shared libraries AFAIK.
-- "Source... The Final Frontier" -- keepersoflists.org
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.
Undiscovered bugs in certain media players?
by
Anonymous Coward
·
· Score: 0
I wonder if there are vulnerable music/movie players that don't perform proper sanity checks on input data. What next, MP3s that make your player execute arbitrary code? Could be.
This ad is getting annoying
by
Anonymous Coward
·
· Score: 0
i may have to pay for the ad-free version... bastards =)
Re:This ad is getting annoying
by
Anonymous Coward
·
· Score: 0
Your host file is: /etc/hosts on most Unix-type systems. c:\winnt\system32\drivers\etc\host on most NT-based systems c:\windows\hosts on most Win9x based systems.
Re:This ad is getting annoying
by
Anonymous Coward
·
· Score: 0
Your host file is: /etc/hosts on most Unix-type systems. c:\winnt\system32\drivers\etc\host on most NT-based systems c:\windows\hosts on most Win9x based systems.
One thing: slashdot.org/cgi-bin is not a valid host. hosts only does hostnames, not URLs
have you dumped your core today?
by
Anonymous Coward
·
· Score: 0
that must be because your rendering routine is still a bit immature. you could try to have a look at your hashtables too. you might have had a bad implementation.
This is obviously the work of Microsoft's Counter Intelligence Program!
Times, the being in a state of flux thereof
by
Anonymous Coward
·
· Score: 0
Seems like we're not allowed to have ANY bugs in our code anymore, at least not for network-connected apps.
Damn, there goes our last avenue of creative expression.
2.2-2.4
by
Anonymous Coward
·
· Score: 0
so i severything after kernal 2.2 having problems - what the fuck? is linus trying to be like m$ and keep making me download fucking updates every week?
Where can I get the PNG of death?
by
TimFreeman
·
· Score: 1
According to one of the
provided links,
the problem was originally discovered when
an invalid PNG file caused libPNG to crash.
I'd like to get this PNG file and throw it
at a development server here at work before
a script kiddie posing as a customer does.
Any idea where I can get the PNG of death?
Meanwhile back at Microsoft
by
WillSeattle
·
· Score: 1, Flamebait
There are no bugs with XP. Or with Win 2000. Or with WinCE.
Really.
Ignore the crashes - it's just your imagination.
Ask yourself - would you rather know about a bug? Or have someone knowledgeable deny it exists? Even when you have a CD with the bug fix installed on another computer.
-
-- ---
Will in Seattle - What are you doing to fight the War?
Re:Meanwhile back at Microsoft
by
The+Bungi
·
· Score: 1, Insightful
It's amazing how you monkeys react to things like these. There's a bug in zlib, yeah. And your response is to say "Microsoft software has more bugs!" Do you really think you're doing anyone a favor by blabbering your pathetic "insight" for the word to see?
Just when I think I'll finally cease to be amazed at the mass of useless posts in this place someone like you proves me wrong.
Re:Meanwhile back at Microsoft
by
Anonymous Coward
·
· Score: 0
thanks for replying to the post and thus modding the parent up to 3. you'll note i posted without the bonus, so it was at 1.
prove me wrong - what I said was true.
Re:Meanwhile back at Microsoft
by
Anonymous Coward
·
· Score: 0
What a chickenshit.
How come you posted your retort as an AC?
What the hell does Microsoft had to do with this problem with zlib?
Re:Meanwhile back at Microsoft
by
The+Bungi
·
· Score: 1
Will - is that you?
thanks for replying to the post and thus modding the parent up to 3. you'll note i posted without the bonus, so it was at 1.
Will, we need to work on your math skills as well - I'm seeing your post at 1 still.
prove me wrong - what I said was true.
The meaning of my post apparently escapes you.
Re:Meanwhile back at Microsoft
by
Anonymous Coward
·
· Score: 1, Informative
Nope, my post is still at 1, but since you posted a 2 post in reply to it, which was deemed Interesting (+1), it now shows up as it's the parent.
So, if someone is browsing at x, and you post at y, and someone replies at z - we get the following
x y z 0 2 2 - you see both 1 1 2 - you see both 1 0 2 - you still see both 2 0 2 - you still see both 3 1 3 - you still see both (pretty cool) 3 -1 3 - you still see both
This is why you shouldn't reply to 0 or -1 posts, unless you wish to legitimize them.
Of course, there's the friend/foe bonus too. And in mine, it adds +1 for some posts (Informative) and -1 for others (Troll).
Brings me back to my game design days...
and yes, it's me.
Re:Meanwhile back at Microsoft
by
Anonymous Coward
·
· Score: 0
and actually, I note it's now Funny (+1), so your bumping it up by posting at 3 really helped it get more notice.
night!
Re:Meanwhile back at Microsoft
by
The+Bungi
·
· Score: 1
So, if someone is browsing at x, and you post at y, and someone replies at z - we get the following
Well that's some pretty complex math you got going there Will! Thank you for teaching me how Slashdot works.
Anyway, I guess you're in a race to redefine "pathetic" - I'll leave you to it.
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
That's better
by
Anonymous Coward
·
· Score: 0, Flamebait
But, still, the safest implementation should always be the default. That's a basic tenet of any computer security study. Linux has already ripped off BSD's VM and TCP/IP stacks; it may as well rip off their superior malloc() implementation as well.
Re:That's better
by
Anonymous Coward
·
· Score: 0
how can you rip off anything given openbsd license?
also, how is the malloc implementation of openbsd superior to that in the parent post? or do you mean the default behaviour?
Linux has already ripped off BSD's VM and TCP/IP stacks; it may as well rip off their superior malloc() implementation as well.
Um no. If they ripped them off as you say they would not be able to licence them as GPL now could they?
-- I know I'm going to hell, I'm just trying to get good seats.
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.
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.
Um okay but AFAIK the TCP stack and VM were not stolen from any where.
If they stole the TCP/IP stack then how come they have a statefull firewall and BSD dose not AFAIK (I could be wrong here).
And they have two competing VM's what did they do steal one from OpenBSD and the other from FreeBSD?.
-- I know I'm going to hell, I'm just trying to get good seats.
Linux has already ripped off BSD's VM and TCP/IP stacks
What a load of bollocks. No wonder you're posting anonymously. Linux, for those that are curious, has a VM system that is generally thought to scale much better than that of the BSDen (with FreeBSD having the most modern VM of the bunch). Linux also has 100% non-BSD-bug-compliant TCP/IP stack as well (see RFC961, if you interested). Just parouse/usr/src/linux/net/ipv4/* if you don't believe me.
-- The wheel is turning, but the hamster is dead.
Re:That's better
by
Anonymous Coward
·
· Score: 0
I *think* Linux (as well as almost every other OS out there) started out with a TCP stack based on *BSD, so the original poster does have some point.
It's the main reason that the Land/Teardrop (I think those were the right ones) attacks were such a big deal, and why they affected almost everything on the 'Net.
If they stole the TCP/IP stack then how come they have a statefull firewall and BSD dose not AFAIK (I could be wrong here).
I think you are....OpenBSD's packet filter is stateful. Don't know about the other BSDs.
-- Admit nothing, deny everything and make counter-accusations.
Re:That's better
by
Anonymous Coward
·
· Score: 0
This is only recent. The BSD License used to have an advertising clause which conflicted with the GPL.
Re:That's better
by
Anonymous Coward
·
· Score: 0
A quick look at the system call table will show that it was probably never based on BSD. Ever.
In Linux, sockets are done via a system call socketcall(), and the libc wraps the socketcall() calls into things like socket() and connect(). In BSD, the kernel has separate system calls for each of these, so there is a socket() interrupt, a connect() interrupt, a bind() interrupt, et cetera.
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:That's better
by
Anonymous Coward
·
· Score: 0
Land yes, teardrop no. Teardrop was a Linux/Windows only thing. And the famous "Ping o' Death" didn't affect the "real" BSD stacks either.
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.
We are drifting WAY OT here but oh well, they have to be based on BSD. BSD invented the socket. but AFAIK (and I could be wrong) the codebase is totally independent.
I have yet to see any evidence that Linux's TCP was stolen from BSD's and it really bugs me wen assumption is treated like fact.
Like for instance when people try to say that Leonardo da Vinci was gay. We don't know this for a fact. The only evidence is that he never married. But a lot of people say that he was gay like it's a fact. Its possible I'll give them that. But it's not a fact
That said until I see some evidence it's just a theory. Just like da Vinci.
-- I know I'm going to hell, I'm just trying to get good seats.
It doesn't matter if they were stolen from BSD. That's the entire point of the BSD license. Share to make the world a better place. The license doesn't require the user to send their updates back up the tree, but it is encouraged. BSD license doesn't even make you distribute the source code, but it is encouraged.
If an application needs to be written because the implementation of a VM has changed (i.e. Linux changed VM implementations, it does not have 2), then the application is broken, not the VM. APIs were invented for a reason.
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.
That's funny in "Just for fun" Linus talks about how they built the first TCP stack out of a sockets interface one guy wrote so he could run X11 on Linux. Another poster pointed out here how the systemcalls are different and there for it is likely that Linux never used a BSD TCP stack.
Do you have the kernel version that they first "stole" the DSB code in. If so I can download it and finaly have conclusive evidance.
-- I know I'm going to hell, I'm just trying to get good seats.
pass out (...) from (my network) to any keep state
and
pass in (...) from any to (a host) port (number) keep state
for ages with IPF. Or am I not reading you right?
Re:That's better
by
Anonymous Coward
·
· Score: 0
If they stole the TCP/IP stack then how come they have a statefull firewall and BSD dose not AFAIK
If MS stole the windows TCP stack from BSD, how come they don't have internet explorer? And they have two competing VM's what did they do steal one from OpenBSD and the other from FreeBSD?.
No, one they stole, one they wrote themselves. I'll leave it as an exercise to the reader to guess which is which.
Re:That's better
by
Anonymous Coward
·
· Score: 0
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.
Big fucking deal. Hey McFly!! Read the windows release notes - it contains the BSD copyright.
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.
...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?
For other arch's, substitute 'ia64' or 'SRPMS' for 'i386' (no s390 yet). Also available on RH62 for i386, alpha & sparc...
It's "fried rice", you plick!
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.
Re:Here's the redhat rpms
by
Anonymous Coward
·
· Score: 0
Anyone notice what a pain in the butt it is to upgrade against this?
There are 22 different RPM's to download, and since I did a "complete" installation of RedHat, I got to gather them all up, and install them all.
No, I don't use most of the statically linked packages, but if it is installed, I'm vunerable.
If only we had the equivalent of DLL hell under Linux, instead of a cut&paste attitude and static linking...maybe I'd only have to replace the library.
Re:Here's the redhat rpms
by
gmkeegan
·
· Score: 1
I forgot that the rpm filename and directory path have a different 'source' designation. Thanks!
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: 0
more proof that linux is developed by children and childish adults, while realOSs are Developed by professionals.
its been said hundreds of times: linux is for children who hate microsoft, bsd is for people who love unix.
Re:Then there's still a problem in glibc malloc()
by
dtrombley
·
· Score: 1
Oooh. After looking at that, I'm definitely in complete agreement with you... I do still wonder about comparative performance, but in this case I suppose it would be very hard to produce a benchmark with any concrete meaning.
Where do you perceive people regarding BSD as inferior? Just in general? I haven't played with it much myself, except doing superficial administrative type things.
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.
Re:Then there's still a problem in glibc malloc()
by
Anonymous Coward
·
· Score: 0
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
THIS SHOULD BE AN ERROR!!
by
Anonymous Coward
·
· Score: 0
In C it is an ERROR to try to free a block of memory more than once! (Read ANSI/ISO 9899:1990.) And to top it off you people are bitching about Linux manifesting this error? HUH? Do you really believe that the OTHER OS's that you mention (Windows etc.) handle this BETTER by letting it SILENTLY SLIP BY and introducing God knows what other sorts of instabilities? Jesus if I make a bug in my code, I want to damn well KNOW about it. Apparently the only OS that is well-behaved enough to let me know about this is Linux. The rest of them will let this gratuitous error go unreported. As a developer THIS IS NOT WHAT YOU WANT!
This is a big WIN for Linux, and a black mark on Windows and the BSDs and all of those other OS's that you mentioned. Letting buggy code silently "slide by" is NO way to promote stability or security. If it was not for Linux we would not even be aware of this zlib bug today. Chances are that some black hats would know about it and be "r00ting" sensitive systems as we speak. Fortunately we have Linux and fortunately we FOUND OUT ABOUT this damn zlib bug before it was too late!
Re:THIS SHOULD BE AN ERROR!!
by
mirabilos
·
· Score: 1
Huh? The libz-bug does only affect Linux, on OpenBSD it does print an error. Ok, I didn't test windoze, but there it depends on the compiler (=library vendor). This is a big LOSS for Linux, to be exact (ok now I know I'll be modded down, but I prefer BSD for exactly this reason: security. Give me arguments for Linux/MacOS/whatever and I'll listen.).
-- My Karma isn't excellent, damn it! (And/. still does not get UTF-8 right in 2012. Wow.)
Re:THIS SHOULD BE AN ERROR!!
by
Anonymous Coward
·
· Score: 0
Oh, for chrissake. Malloc implementation can be fast or robust. Take your pick. Most Linux distributors choose to set their thing up as fast by default, and evidently the BSDs use robust by default.
You *should* only have the robust mode on while debugging, so while Linux may have ended up behind this once, BSD has been running all your programs more slowly...forever.
Re:THIS SHOULD BE AN ERROR!!
by
mirabilos
·
· Score: 1
Even if your argumentation is correct, to prevent lazy programmers from mistakes, the SECURE implementation is to be preferred by default. You can set FAST by environment variables. Content?
-- My Karma isn't excellent, damn it! (And/. still does not get UTF-8 right in 2012. Wow.)
Link to exploitZ please
by
Anonymous Coward
·
· Score: 0
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.
Re:Additional publicity
by
Anonymous Coward
·
· Score: 0
How much slower could free possibly be if it said "if(ptr==NULL) return;" in the code?
Not much, and this is already being done. The real problem is with "free(ptr); free(ptr);"
Re:Additional publicity
by
Anonymous Coward
·
· Score: 0
Nevermind. I see that that would only work if developers set their pointers to NULL after every call to free.
Re:Additional publicity
by
Anonymous Coward
·
· Score: 0
Thanks. I forgot that free(ptr) wouldn't change the value of ptr at all.
Re:Additional publicity
by
Anonymous Coward
·
· Score: 0
Well, the Linux TCP/IP Stack could be classified as an 'internet flaw.' Its not based on the BSD reference design like almost every other stack in common usage. So it diverges from the common design, and has unique bugs.
That's an 'internet flaw' in that it's a flaw that ripples through the whole internet, as Linux is used on more than a few machines, some that are even critical to the net's operation.
It should be a warning
by
Anonymous Coward
·
· Score: 0
and it is. It doesn't silently accept double-frees, it PRINTS A BIG FAT WARNING to stderr and then immediately exits free() without messing up the heap. There is a malloc_option to make these warnings into errors as well, if you're feeling pedantic.
Re:It should be a warning
by
mirabilos
·
· Score: 1
How would you catch the error in standard C, where free() is void, i.e. has no return code?
Believe me or not, the only viable ways are printing an error (warning for the pedantic) message or silently succeeding/ignoring. The former being the default.
-- My Karma isn't excellent, damn it! (And/. still does not get UTF-8 right in 2012. Wow.)
Re:It should be a warning
by
robhancock
·
· Score: 1
How about killing the process, like an assertion failure? Preferably dumping core? That could at least be an option. Wouldn't be great in some situations, but probably better than having the program go into never-never land and possibly causing a security risk..
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.
While your selection of tools is nice (though I've only tried mpatrol, not EF), your macro will only catch a certain class of double free bugs. In case you have two or more pointers to the same malloc'ed block, you would still have an invalid non-NULL pointer after the macro-free.
But don't get me wrong, any improvement is nice.
Re:It should be a warning
by
Anonymous Coward
·
· Score: 0
Actually its worse than that, his macro won't work at all (Pedent I am):
#define FREE(x) free(x);x=NULL;
I feel much better now...
Re:It should be a warning
by
mirabilos
·
· Score: 1
Ok, I ack you on this one - for developers, yes. I hate programmes generating core files by myself, and so this should not be the default - unless you prove me wrong. You might take my comment about lazy coders who don't test for a start, but I don't know whether dumping core is always suitable.
-- My Karma isn't excellent, damn it! (And/. still does not get UTF-8 right in 2012. Wow.)
Re:It should be a warning
by
mirabilos
·
· Score: 1
libglib? Surely you jest...
-- My Karma isn't excellent, damn it! (And/. still does not get UTF-8 right in 2012. Wow.)
Re:It should be a warning
by
Anonymous Coward
·
· Score: 0
And your macro will fail in certain circumstances: if (abc) FREE(xyz); for (xyz=NULL ; cond ; FREE(xyz)) {/* do something */ }/* I know, this example is lame */ Here is a more appropriate definition: #define FREE(x) (free(x), (x) = NULL) Even that will fail in some circumstances: /* Free things on a list */ void** p = list; for (i = listlen ; i > 0 ; --i) FREE(*p++);
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.
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.
Re:It should be a warning
by
mirabilos
·
· Score: 1
I think everyone who considers libglib to be divided by four, then cooked in hot fat and the remainders (and the fat) being melted with glass to radioactive material containers. Seriously. Anything more would just be overkill.
-- My Karma isn't excellent, damn it! (And/. still does not get UTF-8 right in 2012. Wow.)
Microsoft to Focus on Security
by
ditoudi
·
· Score: 1
The Associated Press is reporting that Bill Gates announced to employees Wednesday a major strategy shift across all Linux products to emphasize security and privacy over new capabilities. In e-mail to employees, Gates referred to the new philosophy as "Trustworthy Computing" and called it the "highest priority". Gates said the new emphasis was "more important than any other part of our work.
You're right of course
by
Anonymous Coward
·
· Score: 0
But it's been so long since I've had to fight with Visual C++ (yuck) that I didn't remember exactly what it did:-) Thanks for clearing that up!
-S.Trooper
Re:This is why you clear pointers after freeing th
by
ddstreet
·
· Score: 1
it's trivial to add an assertion checking for a NULL pointer before any free()
From man malloc:
free() frees the memory space pointed to by ptr... If ptr is NULL, no operation is performed.
No need to check for NULL, free handles it.
Re:This is why you clear pointers after freeing th
by
e-Motion
·
· Score: 1
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().
Calling free() on a NULL pointer is a no-op. No check or assertion is needed. Setting the pointer to NULL after freeing the memory is enough to protect yourself from this mistake, assuming that the pointer that you are setting is the only pointer that points to the allocated memory.
Why is it....
by
MikeDataLink
·
· Score: 0, Flamebait
That when Linux has a bug, its "supposedly" but when MS has a bug its "absolutely".
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.
Does it really matter?
by
Anonymous Coward
·
· Score: 0
Its well known, at least in government security circles, that the NSA maintains a stable of hacks in Linux.
You think its hard for NSA guys to pose as well meaning kernel/application developers and put bugs like this in open source projects like openSSH?
Hint, do an ip back trace on email accounts of a certain project's developers.
wrong
by
Anonymous Coward
·
· Score: 0
you're wrong. sorry, you lose. play again? [yn]
Re:This is why you clear pointers after freeing th
by
jim3e8
·
· Score: 1
You are protected from the mistake, but you never know it occurred at all. That's why you need the assertion.
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?
no more than you need to put "I-have-my head-up-Bill-Gates'-ass" in front of your post.
BC
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?)
yourbox:~# apt-get -u update ... Fetched 82.2kB in 3s (22.8kB/s) Reading Package Lists... Done Building Dependency Tree... Done
yourbox:~# apt-get -u upgrade Reading Package Lists... Done Building Dependency Tree... Done The following packages will be upgraded
ppp zlib1g 2 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 280kB of archives. After unpacking 124kB will be used. Do you want to continue? [Y/n] Y ... Setting up ppp (2.3.11-1.5)...
Setting up zlib1g (1.1.3-5.1)...
yourbox:~# dpkg -l | sed -e/ii/d ... yourbox:~#
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.
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}}
Only your world is ruined
by
Anonymous Coward
·
· Score: 0
It's a Linux specific bug, *BSD's have better memory management and the exploit doesn't effect them. Other posts elaborate on this. Next time try reading before posting.:-)
It doesn't matter how serious this bug is
by
Anonymous Coward
·
· Score: 0
It doesn't matter how serious this bug is, because it's already flying through the Media (Bill Gates' CNet for example) that Linux is SUPER VULNERABLE TO HACKERS OH MY GOD. This could have been fixed five seconds after it was found by waving a hair from the beard of RMS, and it wouldn't make a difference. We're fucked now.
Re:now just thow your hands in the air,
by
Anonymous Coward
·
· Score: 0
Bongoloid people wanna bong bong bong....CRAZY, CRAZY...
That will still break. It will try and access something at the memory location 5, which will probably segfault.
What you probably want to do is
int i; #define NULL &i
which would make that resolve to *&i, which wouldn't fail.
Strange then
by
Anonymous Coward
·
· Score: 0
That BSD runs almost all my programmes faster than Linux.
You CAN be fast and robust at the same time. Just because Linux's stupid kiddie programmers can't figure it out doesn't mean it's not possible.
So much for Linux being secure... :)
by
Anonymous Coward
·
· Score: 0
So much for Linux being secure. Just goes to show you that Microsoft isn't the only OS that needs help.
oh well Linus tried....
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"?
Linux and security a true oxymoron
by
Anonymous Coward
·
· Score: 0
Look at all the security issues with Linux just from January to now! People say windows has issues. Come on guys use your heads. Open source is nice, but without some standard guidelines open source becomes open sloppy.
Its sad to see Linux go through so many problems this year, but maybe its not all its cracked up to be. You get what you pay for.
huh?
by
Anonymous Coward
·
· Score: 0
WTF is "UNICS"?!
Idjit...
Re:huh?
by
Anonymous Coward
·
· Score: 0
The way UNIX was originally spelled. The name is actually a bit of a joke. I leave it up to you to figure it out, assuming your pathetic grasp of history and weak brain can actually comprehend it.
Anyway you're just another silly little slashdork with no fucking clue so why don't you just keep your fool mouth shut next time, ok dork.
WTF are you talking about?
by
Anonymous Coward
·
· Score: 0
This is a bug in zlib, a cross-platform library. It is not a bug in Linux.
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.
check your entire system
by
Anonymous Coward
·
· Score: 0
Complaining isn't going to fix your system.
checker: #!/bin/sh nm $1 | grep deflate >/dev/null; if [ $? == 0 ]; then
echo "check $1"; fi;
---- find / -type f -exec./checker {} \; > zlib.evil
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.
Bugs happen in real life.
by
Anonymous Coward
·
· Score: 0
And core libraries should do their best to minimise the effects of such bugs. A double free() is still a problem, but it doesn't take much effort on the part of the library maintainers to reduce the severity of the bug.
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. It definitely will catch double-frees in that mode (it brings up an assertion failure dialog, albeit with a rather cryptic error message). There are other options you can turn on for various degrees of paranoia, going so far as checking the entire heap for corruption every time memory is allocated/deallocated and printing "DAMAGE!" warning messages if it finds any.
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.
The released versions of software like that will be compiled in release mode, which doesn't include all those checks, because they slow down execution. In this situation, if they didn't try to overflow the buffer during the testing process, it wouldn't be caught.
However, Visual Studio.NET is supposed to have an option to check for buffer overflows at runtime in a release build..
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.;))
Re:Pointer aliasing...
by
Anonymous Coward
·
· Score: 0
I dunno, most double frees come from freeing DIFFERENT copies of a pointer. Setting one to NULL won't help in this case...
Do you make this stuff up as you go along? Anything used via a char* or a void* pointer not aliased. But please continue talking out of your ass. Sorry to interrupt your bullshit session.
> Do you make this stuff up as you go along? > Anything used via a char* or a void* pointer not aliased. But please continue talking out > of your ass. Sorry to interrupt your bullshit session.
What the HELL are you talking about?
Here is what pointer aliasing is:
char * c = (char*) malloc(1000); char * d = c; ... free(c); c = NULL; ... free(d);
Note that irrespective of the assignment c = NULL;, the allocated memory is still freed twice. (Of course, the situation is not always this simplistic. Pointers are values so they are copied all the time; when you call a function with a pointer argument, or when you store them in data structures, etc.) Note also that I am using char *. So no, I don't make this stuff up as I go along. If you still think I'm wrong, how about explaining?
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:Internet Explorer too!
by
Anonymous Coward
·
· Score: 0
MS can spin this with their "Open Source is a virus" idea. "We made the mistake of using an open source library, and now your computer has a virus."
Microsoft supports peer review !
by
Renaud
·
· Score: 1
>The most significant efforts I have seen are the Stanford Meta-level Compilation Project [stanford.edu] and the/GS switch in Visual C++.NET [devx.com].
Amusingly enough, in this devx.com article: "There is no substitute for good programming skills and peer code review for discovering and fixing vulnerable code." (emphasis mine)
all right, who wrote this ?
"Michael Howard is a program manager on the Windows 2000 security team."
straight for the horse's mouth...
double free almost impossible to exploit.
by
Anonymous Coward
·
· Score: 1, Insightful
On a single threaded app, a double free is completely harmless with the majority of malloc libraries. This means single-threaded apps such as Apache 1.x is safe. So only a multithreaded app (such as Apache 2.x) could be exploited. But even still, you'd have to know:
- the version of malloc they are using - the heap memory usage pattern of the program
In a multithreaded app, the memory usage is not very deterministic. I don't think anyone will lose any sleep over this.
Re:This is why you clear pointers after freeing th
by
Anonymous Coward
·
· Score: 0
Or people could get a few more languages under their belt, remove the blinkers, and start to realize that C is rarely the most appropriate language to be writing applications in.
It doesn't even take a garbage collection language to prevent most overflows.
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.
Anyone have the patch that fixes the problem?
by
Anonymous Coward
·
· Score: 0
I guess I could dig it out and diff the files myself after the server stops being slashdotted.
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?
I can still smell smoke
by
Anonymous Coward
·
· Score: 0
It may be stamped out on your machine, but has everyone updated their boxes?
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
Anonymous Coward
·
· Score: 0
Are you still beating this dead horse topic to death? Garbage collected languages could not even be in a position to be used for what zlib does due to the speed requirements. Get over it - you need C for raw speed - SSL, zlib, Linux kernel, a browser. Garbage collected apps are not suitable for this task. Tell you what, Tom7, please post your super efficient Java zlib replacement to Slashdot complete with benchmarks comparing it to the C version. Also show how your java version will use four times as much in-process memory as the C version.
Re:Would be impossible in garbage-collected langua
by
Anonymous Coward
·
· Score: 0
Chicken Little, er, I mean Tom7 - you forgot tell tell everyone that the sky is falling! The sky is falling! Oh my gosh - someone made a coding mistake - the world must be over! 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.
Re:Would be impossible in garbage-collected langua
by
Tom7
·
· Score: 1
An AC flames,
> Are you still beating this dead horse topic to > death? Garbage collected languages could not > even be in a position to be used for what zlib > does due to the speed requirements. Get over it > - you need C for raw speed - SSL, zlib, Linux > kernel, a browser. Garbage collected apps are > not suitable for this task.
> Tell you what, Tom7, please post your super > efficient Java zlib replacement to Slashdot > complete with benchmarks comparing it to the C > version. Also show how your java version will > use four times as much in-process memory as the > C version.
ehehe. Did I hit a sore spot?;)
Java is not the only alternative to C, fortunately. (Although, it is probably the easiest to learn for a C programmer.)
Performance is dead. People want programs that work much more than they want programs that are fast.
There may come a day when I need to rewrite zlib in SML. If I do, I'll post benchmarks so we can compare it to the C version. Based on my past experience porting similar code, I think it will be highly competitive. (And of course... security hole free!)
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.
Why was this modded down?
by
Anonymous Coward
·
· Score: 0
Why didn't the zlib authors use purify? It's an excellent program for finding errors double free errors EXACTLY like this.
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:Would be impossible in garbage-collected langua
by
Anonymous Coward
·
· Score: 0
Show me one such high level "safe" language with the performance and low-memory characteristics of C. Lisp? O'Caml? Scheme? Snobol? Please.
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.
Gah! Stop this stupid argument!
by
mortonda
·
· Score: 1
The whole issue is not to use insecure languages like C
I can see that you are not a programmer of software that has high demands. I would never dream of using a DNS, SMTP, IMAP/POP3, LDAP, *SQL, or any major service like that, which was programmed in one of your "safe" languages. Do you *like* having system loads around 40?
Use C when you need performance. Be careful, but don't even dream of using Java, C#, or even perl (I love perl, don't mistake me) when performance is on the line. And I think zlib qualifies as a lib that needs to be fast.
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
Re:Selective, are we? Liar?! In January!
by
Anonymous Coward
·
· Score: 0
how is this true?
In January? I doubt it. Especially when On Sunday March 10 2002 the "new tight lipped" BugTraq does not yet have notice of the 600th exploitable hole found in standard Linux distros.
where did you learn of this in January?
I think you are not telling the truth. I doubt this particular article was rejected.
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.
Bah ... this is stupidiest comment ever
by
apankrat
·
· Score: 1
> 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.
Mwaaahaahaa.... You just showed to entire slashdot that you dont know a thing about Windows and not ashamed of bragging about it. Moreover, *you* not being able to see debug output of CRT library does not mean it does not exists. It just means that you dont know where to look for it.
This is pathetic, who did moderate this crap up ?!
-- 3.243F6A8885A308D313
You are not quite right either
by
Anonymous Coward
·
· Score: 0
CRT behaviour entirely depends on the version of the CRL your proggy is using. All most recent mcvsrt.dlls (at least those coming with w2k and xp) catch all sorts of problems related to the heap management (obviously regardless your build preferences) and report them via (a) SEH exceptions (b) debug stream (similar to one used by DebugOutput. Plus there is pretty flexible control API, which allows you to switch particular checks on and off thus affecting overall memory ops performance. 'Never say never'.
Re:You are not quite right either
by
Anonymous Coward
·
· Score: 0
Bwahahahahaha. Read what you just wrote. And they want you to think this is better than stderr. Pfffllllrrrrbbbt.
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).
free software author farts - news at 10
by
Anonymous Coward
·
· Score: 0
you're right - this is not newsworthy at all. a double free is impossible to exploit. you'd have to know the malloc version, the malloc version's data structures, past heap usage, OS version - too many factors to consider! no web servers accept and actively decode compressed data anyway. go about your business. nothing to see here.
I worked for a company that had a large C program that served requests - for sake of argument, lets call them web page requests. The program leaked so much memory that it had be to killed periodically in order to avoid running into swap space (every few hundred requests or so).
That is a primative form of garbage collection - wait until the garbage has piled up, and then throw it out all at once (sort of like how I implement garbage 'collection' at home actually).
Now, having to start up a complex program takes time, so there was an incentive to increase the life span. Different garbage collectors were tested, commercial, free, and one was chosen and implemented. There was great rejoycing all around from the everything-should-be-garbage-collected people.
Well, the garbage collector was soon completely overrun with garbage, because it is easy to create but takes time to collect. The process would periodically sit and do nothing but collect garbage for tens of seconds as it waded through the 500MB or more of garbage that had been produced since last time. So, the first version won and the garbage collector was removed from the code.
The program went back to being shot in the head every hundred requests or so, and there was great rejoycing from the we-don't-need-no-complex-system-sweeping-through-o ur-data people.
In summary:
1. killing a process every so often is a form of garbage collection. 2. Windows dies periodically, so it is using a form of garbage collection. 3. Windows is not secure, refuting your assertion that all garbage collected code is safe.
Forgive me if I ask a naive question, but why didn't you just free the memory? If allocation/deallocation is too inefficient, you simply write your own specialized routine for the kind of data you're having. For instance for small fixed size data you can have quicker lookup-tables etc. I'm sure there are some libraries for that out there too now.
like previously native heap corruption bug in glibc-glob.c. no doubt there are string of embarrassing security glitches still to be found.
How about JavaVM?
by
Anonymous Coward
·
· Score: 0
I guess that JavaVM also uses zlib via java.util.zip.* classes. At least, on GNU/Linux, it seems JavaVM from Sum does not refere to 'libz.so', but referes to its own 'libzip.so'. So we should care for using inflater/deflater in Java until bug fix release from Sun.
Re:Would be impossible in garbage-collected langua
by
Tom7
·
· Score: 1
> Ok, explain to me how one is going to implement a > Garbage Collector in the kernel?
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.
I'm not suggesting that people go and do that; it's a pretty radical idea. But I don't think it is a ridiculous one.
> If libz was written in anything other than C, it > could not be used in nearly as many applications > as it is currently.
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?
I am more arguing about application software than systems software. So if this is truly "systems" software, I've got a much harder argument. But I think it's likely we could get away with a high level language library for applications and a small C program for decompression only for the boot loader.
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:Selective, are we? Liar?! In January!
by
Anonymous Coward
·
· Score: 0
Actually, FreeBSD and OpenBSD both fixed this bug back in January. They didn't consider it a security issue because their malloc() uses some sane defaults. Get the clue yet?
Re:So much for "many eyes"....
by
Anonymous Coward
·
· Score: 0
its linux fags like you that give linux a bad name.
At last!
by
Anonymous Coward
·
· Score: 0, Funny
An effective defense against slashdotting!
Just load BrowserKiller.png on your home page and bring on the traffic.
Re:Would be impossible in garbage-collected langua
by
jonabbey
·
· Score: 2
Re:Would be impossible in garbage-collected langua
by
Anonymous Coward
·
· Score: 0
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.
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.
(Sounds like you need to do some more learning!)
Sounds like you're a pompous no-nothing jackass.
Re:This is why you clear pointers after freeing th
by
Anonymous Coward
·
· Score: 0
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.
And were you the person who advocated that the client use C in the first place for their application?
You almost seem to be suggesting that maintaining old applications that have already chosen C or C++ (for presumably less than good reasons) is a good reason to choose C for new applications.
I'll grant you that with a few years C coding experience under your belt, you can code defensively and make C almost safe, but then what of the other coders who will work on the project?
Re:Would be impossible in garbage-collected langua
by
Anonymous Coward
·
· Score: 0
ehehe. Did I hit a sore spot?;)
Of course you hit a sore spot - every time one of these things comes up in an app that didn't require C, every coder who's seen beyond C and C++ either groans (the mature ones), or laughs (the immature ones).
There are many immature programmers out there.
C and C++ coders don't like being laughed at.
:)
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:Would be impossible in garbage-collected langua
by
Anonymous Coward
·
· Score: 0
That was a rhetorical question.;)
Re:This is why you clear pointers after freeing th
by
Anonymous Coward
·
· Score: 0
In my first reply to your post I wrote:
but then what of the other coders who will work on the project?
It just occurred to me that the number of people who wrote to correct you on having a check or assertion before freeing a potentionally null pointer should illustrate the point I made above (even if someone them just misunderstood you).
Re:Would be impossible in garbage-collected langua
by
Anonymous Coward
·
· Score: 0
That was a rhetorical question.;)
And the reply was a joke.;)
I just wanted to make the point that there is an entire legion of programmers out there as immature as I am.:)
Re:Selective, are we? Liar?! In January!
by
Anonymous Coward
·
· Score: 0
I will have to start reading bsd patch mail lists and stop thinking BugTraq is authoritative anymore.... Hell it seams they are in the pocket of Bill Gates now anyways.
I am sorry. Its just that I never thought I would see the year in which I could no longer trust BugTraq.
You showed me I am in for a harsh letdown.
sorry again.
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.
Your macro replaces free(p) with a string. Your compiler may warn you that your code has useless expression, but don't depend on it.
Even without the quotes, that's the wrong way to write a multi-statement macro. Consider, for example:
if (p_no_longer_needed) free(p)
After macro expansion, your p=NULL statement would be evaluated regardless of the value of p_no_longer_needed. For simple expressions such as this one, using the comma operator instead of the semicolon would be sufficient. In general, though, you should use do {... } while(0) for multi-statement macros.
Macros that evaluate their arguments multiple times should be clearly recognizable as macros. While your macro may be a quick fix that lets you get away with not having to modify a lot of your existing code, it eventually may cause even more problems down the line, especially if someone else is maintaining your code and has overlooked your subtle macro definition.
Re:Clear pointers
by
Anonymous Coward
·
· Score: 0
Don't expect that to work in C++ code. Take this code for example:
"Is the double free covered by the double GPL"
by
da5idnetlimit.com
·
· Score: 1
You mean, as in "Information wants to be free ?"
Well, yes, seems this bug will allow your data to be free of your computer and to disseminate on the Net...
Ok you guys at the FSF, I think I found the loop here. We now have to PROPAGATE bugs to FREE more Information...
Maybe I should stop coffee, too...
-- It takes 40+ muscles to frown, but only four to extend your arm and bitchslap the motherfucker
Wha???!?!
by
Anonymous Coward
·
· Score: 0
You mean Linux has a security bug?? OMG I thought only Microsoft was fallible! HAHHAHAHHAH
My servers are already patched.
by
Anonymous Coward
·
· Score: 0
Way to go, Debian! If this was a MS issue how many months would it take to make a 'Service Pack' available?
Re:Would be impossible in garbage-collected langua
by
Anonymous Coward
·
· Score: 0
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.
The competition was to do the best compression, not to run in a few seconds - I could write a interpretted BASIC entry that ran in under a second but it wouldn't get the best compression. On top of this there was a time limit by which programs had to finish (a limit much shorter than I assume a brute force search would have taken), so if the programmers chose to think harder rather than smarter, C would have had its advantage.
Personally I think the reason C never wins is it's a slow language to develop in, and most entries are probably from academics and students with free time on their hands who havn't been stuck at jobs working on a C project for the past few years, and so are unlikely to choose C as the most appropriate langauge.
Exploit OpenSSH ;)
by
Anonymous Coward
·
· Score: 0
Because if we can't connect to our remote machines, it will be really easy to convince my boss, that I peronally have to fix the problems in our datacenters in Hawaii, Papeete & Sydney
Er, YES!
-- ich bin der musikant
mit taschenrechner in der hand
kraftwerk
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
partingshot
·
· Score: 1
"So if this is truly "systems" software, I've got a much harder argument"
Re:Would be impossible in garbage-collected langua
by
Tom7
·
· Score: 1
Well, as much as I like an architecture built for high level functional languages, I definitely think it would be hard to convince Intel to switch the IA64 to LISP64 and convince linus to totally rewrite the kernel.
What I'm actually proposing is pretty easy: Applications don't have a high degree of interaction with low-level code, and can be easily written in high-level languages.
Damn Microsoft!
by
Anonymous Coward
·
· Score: 0
They should've tested zlib more before releasing it! Sheesh. What kind of security crap is this? They should be ashamed of themselves. Linux Rules!!!
Oh wait...
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
RazzleDazzle
·
· Score: 1
Yeah everyone makes mistakes, including the kings of code review, the OpenBSD crew. Let's look at an e-mail in the misc mailing list posted March 12 by Todd Miller. ---------- > OpenBSD as a whole, until a few hours ago, was vulnerable to the flaw in > any program that used libz (I count 7 in/usr/bin) would double free. It > just so happens that double freeing reports a warning instead of > corrupting the heap.
Actually, I committed a fix for the problem in January. We didn't realize it was a security problem at the time (and neither did the zlib folks).
- todd ---------- fixed before all the hoopla atta go guys.
-- ZERO ZERO ONE ZERO ONE ZERO ONE ONE! Just brushing up for my next big invention: Ethernet over Voice (EoV)
Ackem!
by
Anonymous Coward
·
· Score: 0
Nice news topic, pity it should read something like "Flaw leaves Linux computers vulnerable"!!!
Your just a bunch of biased users. Always covering up your asses and never to admit the truth.
I ran various Linux Distributions for 2 months, its f**kin buggy as. Dont get me started about KDE & GNOME. Linux is just a pipe dream.
The UNIX & WINDOWS platforms will always dominate the market, SO STOP TRYING!
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.
a bug in ZLIB???
by
timecop
·
· Score: 0, Insightful
What the hell is wrong with you people? And you complain when there is a bug found in command.com?
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:So much for "many eyes"....
by
carlos_benj
·
· Score: 1
Guilty.
--
--
As a matter of fact, I am a lawyer. But I play an actor on TV.
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
Tom7
·
· Score: 1
I'm not sure what your point is -- C++ has value semantics strings by using reference counting, but the same trick does not scale well to something like a tree data structure.
> 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.
I guess the penalty is "not having to manage his/her own memory", or something like that? Though the loss of control can be significant for some applications (like the kernel or embedded devices), I really don't think it is important for most of the kinds of projects that people use C and C++ for. Much more important is correctness, and as we see time and time again, even "good programmers" make mistakes that can sometimes be devastating.
If you mean a performance penalty, well, GC overhead can be very low, and can also improve the performance of applications (heap compaction is important for long-running apps, and allocation is typically faster than malloc in a GC system). (And just because the JVM is inefficient doesn't mean that all GC'd languages are!;)) Spending less time managing low-level details gives you more time to optimize algorithms, which all good programmers know is where the real speed gains are.
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.
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]
incase of /. effect
Zdnet . And this one is a little, emphsis on a little, bit more techincal. Cause cnet is for the mindless sometimes.
"If a quarter is two bits, then a dollar's a byte." -R Deric Miller
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
But will this affect other systemes using the zlib, such as FreeBSD or many open-sourced Windows softwares? This article is near empty of useful information. If a security-minded person is out there, please give us Slashdotters more information so we can protect our systemes! :-/
Sincerely yours,
Chloë
From the article: " The Computer Emergency Response Team (CERT) Coordination Center at Carnegie Mellon University is expected to release more information Monday afternoon"
It also says they "could not be reached for comment".
ASCII tastes bad dude.
Binary it is then.
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...
it says on http://www.zlibc.org How's that for fast service? :)
Karma: Bad (but who really cares anyway?)
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.
The only things running on my boxen are:
Apache (no gzip) and proftpd.
I think I'm alright.
I know I'm going to hell, I'm just trying to get good seats.
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.
Impossible? Not at all -- only a foolish person would claim such a thing, and I don't believe that any respectable member of the community would claim it.
Less likely to occur? Arguably. I won't start that discussion.
Fixed more quickly? I guess we'll find out soon enough.
Anyone who reads this site.
Your post will never get modded up as insightful. That's just wrong.
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?
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));
Seems to indicate packages that should be immediately upgraded.
Security Bulletin here.
Sorry for the earlier Freudian slip.. /.'ed.. Yet...
The website is at http://www.zlib.org and they have just updated their website and it's not
Sorry for the earlier wrong link..
Karma: Bad (but who really cares anyway?)
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 am not worrying about Windows so much as I am my FreeBSD and OpenBSD boxes; I assume they all utilise the same zlib functions, and thus would possibly be open to attaque as well. I only ask of Windows because I know many Windows softwares (such as Mozilla) use the zlib as well.
Sincerely yours,
Chloë
Aren't you supposed to say - First Anti-Microsoft Post before you type anything else?
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.
cool. i task you with rewriting all of linux in modula-3. see ya in a couple of years.
I always wonder when a nice buq comes around how long it will take before i get exploited and darn i get exploited, but then i can only blame my self for not upgrading.
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........
I love reading bugtraq a day later on slashdot.
----
All of whose base are belong to the what-now?
The patch is already out. The thing that really sucks is how many packages use a statically compiled version of zlib. I now have to upgrade 22 seperate packages on my Redhat 7.2 box. Fun fun fun...
This sig has been temporarily disconnected or is no longer in service
Why do I think that this headline
smells like one step in an orchestrated
machievical plot of FUD?
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.
Surely this kind of problem could be easily avoided if the developers had used 'purify' to check for memory leaks. Or are the open-sourcers too high and mighty to use 'proprietary' software even when it would improve the quality of their code ?
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... :(
On another topic:
The ad at the top of the page says, "Chicks dig case mods." Is there any wonder why VA software doesn't make money?
2002-1-23 21:23:51 zLib Buffer Overflows(articles,news) (rejected)
Job? I don't have time to get a job! Who will sit around and bitch about being broke and unemployed then?
Funny, wan't this supposed to be impossible under Open Source?
/. at -1!
Yes, it is impossible to introduce a bug in Linux code. It just can't happen.
I'd say this is more a demonstration of the "many eyes" principle at work (unless the RedHat employee who reported it has no eyes).
Seriously, it looks like maybe it isn't so simple. In the "golden days" a lot of companies bought into the idea that Open Source code was free from these types of major flaws... now they see this isn't true.
Still waiting for the "serious" part here. I don't know of a consensus among companies that postulated that view at any point in Linux history.
So, when the glow is off the rose we see that Linux is no more reliable (thanks to 4.2) and no more secure than a well maintained Windows 2000/XP system.
I don't think you're taking the glow off the rose as much as shaking the dew from the lilly here.
Fight tyranny and repression.... read
If this was an indication of your well reasoned response, that's the only way your posts will be read then. Don't mistake tasteful discretion for tyrannical repression, it'll only make you paranoid.
--
As a matter of fact, I am a lawyer. But I play an actor on TV.
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
Oh those large ad's are so annyoing! Can I please pay so I don't have to look at them! ;)
Didn't the previous Slashdot story claim how "Everyone seems to know ... Linux is safer than Windows"???
LOL at how biased some articles are!
https://www.accountkiller.com/removal-requested
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.
I wonder if there are vulnerable music/movie players that don't perform proper sanity checks on input data. What next, MP3s that make your player execute arbitrary code? Could be.
i may have to pay for the ad-free version... bastards =)
that must be because your rendering routine is still a bit immature. you could try to have a look at your hashtables too. you might have had a bad implementation.
This is obviously the work of Microsoft's Counter Intelligence Program!
Seems like we're not allowed to have ANY bugs in our code anymore, at least not for network-connected apps.
Damn, there goes our last avenue of creative expression.
so i severything after kernal 2.2 having problems - what the fuck? is linus trying to be like m$ and keep making me download fucking updates every week?
According to one of the provided links, the problem was originally discovered when an invalid PNG file caused libPNG to crash. I'd like to get this PNG file and throw it at a development server here at work before a script kiddie posing as a customer does. Any idea where I can get the PNG of death?
There are no bugs with XP.
Or with Win 2000.
Or with WinCE.
Really.
Ignore the crashes - it's just your imagination.
Ask yourself - would you rather know about a bug? Or have someone knowledgeable deny it exists? Even when you have a CD with the bug fix installed on another computer.
-
--- Will in Seattle - What are you doing to fight the War?
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
But, still, the safest implementation should always be the default. That's a basic tenet of any computer security study. Linux has already ripped off BSD's VM and TCP/IP stacks; it may as well rip off their superior malloc() implementation as well.
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?
ftp://updates.redhat.com/7.2/en/os/i386/zlib-1.1.3 -25.7.i386.rpm
For other arch's, substitute 'ia64' or 'SRPMS' for 'i386' (no s390 yet). Also available on RH62 for i386, alpha & sparc...
It's "fried rice", you plick!
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
In C it is an ERROR to try to free a block of memory more than once! (Read ANSI/ISO 9899:1990.) And to top it off you people are bitching about Linux manifesting this error? HUH? Do you really believe that the OTHER OS's that you mention (Windows etc.) handle this BETTER by letting it SILENTLY SLIP BY and introducing God knows what other sorts of instabilities? Jesus if I make a bug in my code, I want to damn well KNOW about it. Apparently the only OS that is well-behaved enough to let me know about this is Linux. The rest of them will let this gratuitous error go unreported. As a developer THIS IS NOT WHAT YOU WANT!
This is a big WIN for Linux, and a black mark on Windows and the BSDs and all of those other OS's that you mentioned. Letting buggy code silently "slide by" is NO way to promote stability or security. If it was not for Linux we would not even be aware of this zlib bug today. Chances are that some black hats would know about it and be "r00ting" sensitive systems as we speak. Fortunately we have Linux and fortunately we FOUND OUT ABOUT this damn zlib bug before it was too late!
I wanna 0wN some L1nu> b0x35!!!!!!!!
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 it is. It doesn't silently accept double-frees, it PRINTS A BIG FAT WARNING to stderr and then immediately exits free() without messing up the heap. There is a malloc_option to make these warnings into errors as well, if you're feeling pedantic.
The Associated Press is reporting that Bill Gates announced to employees Wednesday a major strategy shift across all Linux products to emphasize security and privacy over new capabilities. In e-mail to employees, Gates referred to the new philosophy as "Trustworthy Computing" and called it the "highest priority". Gates said the new emphasis was "more important than any other part of our work.
-S.Trooper
From man malloc:
No need to check for NULL, free handles it.
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().
Calling free() on a NULL pointer is a no-op. No check or assertion is needed. Setting the pointer to NULL after freeing the memory is enough to protect yourself from this mistake, assuming that the pointer that you are setting is the only pointer that points to the allocated memory.
That when Linux has a bug, its "supposedly" but when MS has a bug its "absolutely".
Just an observation....
Mike @ The Geek Pub. Let's Make Stuff!
Its well known, at least in government security circles, that the NSA maintains a stable of hacks in Linux.
You think its hard for NSA guys to pose as well meaning kernel/application developers and put bugs like this in open source projects like openSSH?
Hint, do an ip back trace on email accounts of a certain project's developers.
you're wrong.
sorry, you lose. play again? [yn]
You are protected from the mistake, but you never know it occurred at all. That's why you need the assertion.
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?
no more than you need to put "I-have-my head-up-Bill-Gates'-ass" in front of your post. BC
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?)
Speaking of Monkeys!
yourbox:~# apt-get -u update
...
...
/ii/d
...
Fetched 82.2kB in 3s (22.8kB/s)
Reading Package Lists... Done
Building Dependency Tree... Done
yourbox:~# apt-get -u upgrade
Reading Package Lists... Done
Building Dependency Tree... Done
The following packages will be upgraded
ppp zlib1g
2 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 280kB of archives. After unpacking 124kB will be used.
Do you want to continue? [Y/n] Y
...
Setting up ppp (2.3.11-1.5)
Setting up zlib1g (1.1.3-5.1)
yourbox:~# dpkg -l | sed -e
...
yourbox:~#
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
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}}
It's a Linux specific bug, *BSD's have better memory management and the exploit doesn't effect them. Other posts elaborate on this. Next time try reading before posting. :-)
It doesn't matter how serious this bug is, because it's already flying through the Media (Bill Gates' CNet for example) that Linux is SUPER VULNERABLE TO HACKERS OH MY GOD. This could have been fixed five seconds after it was found by waving a hair from the beard of RMS, and it wouldn't make a difference. We're fucked now.
Bongoloid people wanna bong bong bong....CRAZY, CRAZY...
#define NULL 5
while(1)
{
if (x=*NULL)
break;
}
You CAN be fast and robust at the same time. Just because Linux's stupid kiddie programmers can't figure it out doesn't mean it's not possible.
So much for Linux being secure. Just goes to show you that Microsoft isn't the only OS that needs help.
oh well Linus tried....
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"?
Look at all the security issues with Linux just from January to now! People say windows has issues. Come on guys use your heads. Open source is nice, but without some standard guidelines open source becomes open sloppy.
Its sad to see Linux go through so many problems this year, but maybe its not all its cracked up to be. You get what you pay for.
WTF is "UNICS"?!
Idjit...
This is a bug in zlib, a cross-platform library. It is not a bug in Linux.
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}}
Complaining isn't going to fix your system.
/dev/null;
./checker {} \; > zlib.evil
checker:
#!/bin/sh
nm $1 | grep deflate >
if [ $? == 0 ]; then
echo "check $1";
fi;
----
find / -type f -exec
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.
And core libraries should do their best to minimise the effects of such bugs. A double free() is still a problem, but it doesn't take much effort on the part of the library maintainers to reduce the severity of the bug.
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
>The most significant efforts I have seen are the Stanford Meta-level Compilation Project [stanford.edu] and the /GS switch in Visual C++.NET [devx.com].
Amusingly enough, in this devx.com article:
"There is no substitute for good programming skills and peer code review for discovering and fixing vulnerable code."
(emphasis mine)
all right, who wrote this ?
"Michael Howard is a program manager on the Windows 2000 security team."
straight for the horse's mouth...
On a single threaded app, a double free is completely harmless with the majority of malloc libraries. This means single-threaded apps such as Apache 1.x is safe. So only a multithreaded app (such as Apache 2.x) could be exploited. But even still, you'd have to know:
- the version of malloc they are using
- the heap memory usage pattern of the program
In a multithreaded app, the memory usage is not very deterministic.
I don't think anyone will lose any sleep over this.
Or people could get a few more languages under their belt, remove the blinkers, and start to realize that C is rarely the most appropriate language to be writing applications in.
It doesn't even take a garbage collection language to prevent most overflows.
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.
I guess I could dig it out and diff the files myself after the server stops being slashdotted.
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
It may be stamped out on your machine, but has everyone updated their boxes?
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.
Are you still beating this dead horse topic to death? Garbage collected languages could not even be in a position to be used for what zlib does due to the speed requirements. Get over it - you need C for raw speed - SSL, zlib, Linux kernel, a browser. Garbage collected apps are not suitable for this task.
Tell you what, Tom7, please post your super efficient Java zlib replacement to Slashdot complete with benchmarks comparing it to the C version. Also show how your java version will use four times as much in-process memory as the C version.
Chicken Little, er, I mean Tom7 - you forgot tell tell everyone that the sky is falling! The sky is falling!
Oh my gosh - someone made a coding mistake - the world must be over!
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.
An AC flames,
;)
> Are you still beating this dead horse topic to
> death? Garbage collected languages could not
> even be in a position to be used for what zlib
> does due to the speed requirements. Get over it
> - you need C for raw speed - SSL, zlib, Linux
> kernel, a browser. Garbage collected apps are
> not suitable for this task.
> Tell you what, Tom7, please post your super
> efficient Java zlib replacement to Slashdot
> complete with benchmarks comparing it to the C
> version. Also show how your java version will
> use four times as much in-process memory as the
> C version.
ehehe. Did I hit a sore spot?
Java is not the only alternative to C, fortunately. (Although, it is probably the easiest to learn for a C programmer.)
Performance is dead. People want programs that work much more than they want programs that are fast.
There may come a day when I need to rewrite zlib in SML. If I do, I'll post benchmarks so we can compare it to the C version. Based on my past experience porting similar code, I think it will be highly competitive. (And of course... security hole free!)
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.
Why didn't the zlib authors use purify? It's an excellent program for finding errors double free errors EXACTLY like this.
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.
Show me one such high level "safe" language with the performance and low-memory characteristics of C. Lisp? O'Caml? Scheme? Snobol? Please.
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.
I can see that you are not a programmer of software that has high demands. I would never dream of using a DNS, SMTP, IMAP/POP3, LDAP, *SQL, or any major service like that, which was programmed in one of your "safe" languages. Do you *like* having system loads around 40?
Use C when you need performance. Be careful, but don't even dream of using Java, C#, or even perl (I love perl, don't mistake me) when performance is on the line. And I think zlib qualifies as a lib that needs to be fast.
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
how is this true?
In January? I doubt it. Especially when On Sunday March 10 2002 the "new tight lipped" BugTraq does not yet have notice of the 600th exploitable hole found in standard Linux distros.
where did you learn of this in January?
I think you are not telling the truth. I doubt this particular article was rejected.
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.
> 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.
.... You just showed to entire slashdot that you dont know a thing about Windows and not ashamed of bragging about it. Moreover, *you* not being able to see debug output of CRT library does not mean it does not exists. It just means that you dont know where to look for it.
Mwaaahaahaa
This is pathetic, who did moderate this crap up ?!
3.243F6A8885A308D313
CRT behaviour entirely depends on the version of the CRL your proggy is using. All most recent mcvsrt.dlls (at least those coming with w2k and xp) catch all sorts of problems related to the heap management (obviously regardless your build preferences) and report them via (a) SEH exceptions (b) debug stream (similar to one used by DebugOutput. Plus there is pretty flexible control API, which allows you to switch particular checks on and off thus affecting overall memory ops performance. 'Never say never'.
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).
you're right - this is not newsworthy at all.
a double free is impossible to exploit.
you'd have to know the malloc version, the malloc version's data structures, past heap usage, OS version - too many factors to consider!
no web servers accept and actively decode compressed data anyway.
go about your business. nothing to see here.
I worked for a company that had a large C program that served requests - for sake of argument, lets call them web page requests. The program leaked so much memory that it had be to killed periodically in order to avoid running into swap space (every few hundred requests or so).
o ur-data people.
That is a primative form of garbage collection - wait until the garbage has piled up, and then throw it out all at once (sort of like how I implement garbage 'collection' at home actually).
Now, having to start up a complex program takes time, so there was an incentive to increase the life span. Different garbage collectors were tested, commercial, free, and one was chosen and implemented. There was great rejoycing all around from the everything-should-be-garbage-collected people.
Well, the garbage collector was soon completely overrun with garbage, because it is easy to create but takes time to collect. The process would periodically sit and do nothing but collect garbage for tens of seconds as it waded through the 500MB or more of garbage that had been produced since last time. So, the first version won and the garbage collector was removed from the code.
The program went back to being shot in the head every hundred requests or so, and there was great rejoycing from the we-don't-need-no-complex-system-sweeping-through-
In summary:
1. killing a process every so often is a form of garbage collection.
2. Windows dies periodically, so it is using a form of garbage collection.
3. Windows is not secure, refuting your assertion that all garbage collected code is safe.
like previously native heap corruption bug in glibc-glob.c. no doubt there are string of embarrassing security glitches still to be found.
I guess that JavaVM also uses zlib via java.util.zip.* classes. At least, on GNU/Linux,
it seems JavaVM from Sum does not refere to 'libz.so', but referes to its own 'libzip.so'. So we should care for using inflater/deflater in Java until bug fix release from Sun.
> Ok, explain to me how one is going to implement a
> Garbage Collector in the kernel?
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.
I'm not suggesting that people go and do that; it's a pretty radical idea. But I don't think it is a ridiculous one.
> If libz was written in anything other than C, it
> could not be used in nearly as many applications
> as it is currently.
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?
I am more arguing about application software than systems software. So if this is truly "systems" software, I've got a much harder argument. But I think it's likely we could get away with a high level language library for applications and a small C program for decompression only for the boot loader.
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!)
Actually, FreeBSD and OpenBSD both fixed this bug back in January. They didn't consider it a security issue because their malloc() uses some sane defaults. Get the clue yet?
its linux fags like you that give linux a bad name.
An effective defense against slashdotting!
Just load BrowserKiller.png on your home page and bring on the traffic.
Only four times?
- jon
Ganymede, a GPL'ed metadirectory for UNIX
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.
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.
(Sounds like you need to do some more learning!)
Sounds like you're a pompous no-nothing jackass.
You almost seem to be suggesting that maintaining old applications that have already chosen C or C++ (for presumably less than good reasons) is a good reason to choose C for new applications.
I'll grant you that with a few years C coding experience under your belt, you can code defensively and make C almost safe, but then what of the other coders who will work on the project?
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?
That was a rhetorical question. ;)
I just wanted to make the point that there is an entire legion of programmers out there as immature as I am.
I will have to start reading bsd patch mail lists and stop thinking BugTraq is authoritative anymore.... Hell it seams they are in the pocket of Bill Gates now anyways.
I am sorry. Its just that I never thought I would see the year in which I could no longer trust BugTraq.
You showed me I am in for a harsh letdown.
sorry again.
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
Quick fix:
#define free(p) "free(p); p=NULL"
You mean, as in "Information wants to be free ?"
Well, yes, seems this bug will allow your data to be free of your computer and to disseminate on the Net...
Ok you guys at the FSF, I think I found the loop here. We now have to PROPAGATE bugs to FREE more Information...
Maybe I should stop coffee, too...
It takes 40+ muscles to frown, but only four to extend your arm and bitchslap the motherfucker
You mean Linux has a security bug?? OMG I thought only Microsoft was fallible! HAHHAHAHHAH
Way to go, Debian! If this was a MS issue how many months would it take to make a 'Service Pack' available?
The competition was to do the best compression, not to run in a few seconds - I could write a interpretted BASIC entry that ran in under a second but it wouldn't get the best compression. On top of this there was a time limit by which programs had to finish (a limit much shorter than I assume a brute force search would have taken), so if the programmers chose to think harder rather than smarter, C would have had its advantage.
Personally I think the reason C never wins is it's a slow language to develop in, and most entries are probably from academics and students with free time on their hands who havn't been stuck at jobs working on a C project for the past few years, and so are unlikely to choose C as the most appropriate langauge.
http://www.digitaloffense.net/openssh_zlib/
Er, YES!
ich bin der musikant
mit taschenrechner in der hand
kraftwerk
> 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.
"So if this is truly "systems" software, I've got a much harder argument"
- 20 .html
No you don't. See the link below for one idea.
http://www.faqs.org/faqs/lisp-faq/part2/section
Anonymous posts are filtered.
Well, as much as I like an architecture built for high level functional languages, I definitely think it would be hard to convince Intel to switch the IA64 to LISP64 and convince linus to totally rewrite the kernel.
What I'm actually proposing is pretty easy: Applications don't have a high degree of interaction with low-level code, and can be easily written in high-level languages.
They should've tested zlib more before releasing it! Sheesh. What kind of security crap is this? They should be ashamed of themselves. Linux Rules!!!
Oh wait...
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));
Yeah everyone makes mistakes, including the kings of code review, the OpenBSD crew. Let's look at an e-mail in the misc mailing list posted March 12 by Todd Miller. /usr/bin) would double free. It
----------
> OpenBSD as a whole, until a few hours ago, was vulnerable to the flaw in
> any program that used libz (I count 7 in
> just so happens that double freeing reports a warning instead of
> corrupting the heap.
Actually, I committed a fix for the problem in January. We didn't
realize it was a security problem at the time (and neither did the
zlib folks).
- todd
----------
fixed before all the hoopla
atta go guys.
ZERO ZERO ONE ZERO ONE ZERO ONE ONE! Just brushing up for my next big invention: Ethernet over Voice (EoV)
Nice news topic, pity it should read something like "Flaw leaves Linux computers vulnerable"!!!
Your just a bunch of biased users. Always covering up your asses and never to admit the truth.
I ran various Linux Distributions for 2 months, its f**kin buggy as. Dont get me started about KDE & GNOME. Linux is just a pipe dream.
The UNIX & WINDOWS platforms will always dominate the market, SO STOP TRYING!
> 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.
What the hell is wrong with you people? And you complain when there is a bug found in command.com?
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));
Guilty.
--
As a matter of fact, I am a lawyer. But I play an actor on TV.
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));
I'm not sure what your point is -- C++ has value semantics strings by using reference counting, but the same trick does not scale well to something like a tree data structure.
;)) Spending less time managing low-level details gives you more time to optimize algorithms, which all good programmers know is where the real speed gains are.
> 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.
I guess the penalty is "not having to manage his/her own memory", or something like that? Though the loss of control can be significant for some applications (like the kernel or embedded devices), I really don't think it is important for most of the kinds of projects that people use C and C++ for. Much more important is correctness, and as we see time and time again, even "good programmers" make mistakes that can sometimes be devastating.
If you mean a performance penalty, well, GC overhead can be very low, and can also improve the performance of applications (heap compaction is important for long-running apps, and allocation is typically faster than malloc in a GC system). (And just because the JVM is inefficient doesn't mean that all GC'd languages are!
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));