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.
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
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.
Credit where credit is due...
by
ubiquitin
·
· Score: 4, Interesting
Re:Credit where credit is due...
by
weave
·
· Score: 2
Interesting, so a coder inside Redhat finds it, fixes it, releases a fix.
Here's an exercise, and I don't know the answer. But of all the security alerts released by linux vendors and microsoft, what percentage of each is the result of an internal discovery versus someone outside reporting it and the vendor having to make a fix?
Dumb security question
by
wrinkledshirt
·
· Score: 4, Interesting
On the stuff I've been reading about finding and fixing buffer overflows, it seems like it's generally not too hard to spot where these things could potentially happen.
My question is this: How feasible would it be for someone to take a computer and have it do nothing but pattern-matching through all the source code in a typical Linux distribution, looking specifically for problem areas like these? Obviously we couldn't rely on it as a foolproof audit, but has something like this ever been considered?
--
--------
Bleah! Heh heh heh... BLEAH BLEAH!!! Ha ha ha ha...
Re:Dumb security question
by
SirSlud
·
· Score: 5, Interesting
Some software packages do this.. purify, etc. They're pretty expensive tho. The problem is that the logic that results in a buffer overflow error can be VERY complicated, and so its extremely difficult to spot sometimes even for the seasoned developer, nevermind a clever regex.
On the flip side, finding lots of memcpy's instead of strncpy might help you find the 'dumb' overflow bugs, but one would hope those arn't the ones we're most concerned about.:P Mostly, when copying and moving and generally playing with memory, if you spot functions without buffer limit or max byte limit arguments, you *might* be openening yourself up for trouble. Unfortunately, as I said, those are the easy ones.:) In reality, buffer overflow errors (and off-by-one bugs generally follow the 'simple errors can result from terribly complicated logic' construct of buffer overflow bugs) can be extremely difficult to spot if your input parsing/copying/moving mechanism is non-trivial.
-- "Old man yells at systemd"
Re:Dumb security question
by
Kamel+Jockey
·
· Score: 2, Interesting
How feasible would it be for someone to take a computer and have it do nothing but pattern-matching through all the source code in a typical Linux distribution...
A pattern matched theoretically could work (you would need some pretty bitchin' patterns though). However, what will definitly work is a meta-compiler which explicity looks for these problems in code. The most straightforward way to implement this is to use some sort of logic programming language (e.g., SML, Prolog, etc.) to act as a code-verifier, to prove (not just test, but actually prove in a mathematical sense). A meta-compiler could check to see that all malloc's are freed, all new's deleted, all bounds checking is enforced, etc. It is a very intensive process though, but because of these of which parsers can be written which convert code into a universally understandable syntax (independent of whitespace, coding style, etc., note that this is done by all compilers), this could be done.
Of course, the most effective way to solve this problem is to ensure that code is reviewed by someone other than the author so that these kinds of problems can be fixed.
-- In case of fire, do not use elevator. Use water!
Re:Dumb security question
by
Carnage4Life
·
· Score: 4, Informative
On the stuff I've been reading about finding and fixing buffer overflows, it seems like it's generally not too hard to spot where these things could potentially happen.
From this statement I assume you are not a programmer. Buffer overflows caused by using known unsafe library functions (e.g. strcpy, strcat, gets, etc.) can be handled by simple pattern matching but actually investigating the code to make sure every memory/array access does not go out of bounds is not a simple pattern matching problem.
Re:Dumb security question
by
frantzdb
·
· Score: 2
My understanding is that going through source to find possible run-time bugs is often not computable. Certainally you could find some things (x = *NULL will always fail, for instance, and while(1) will never halt), but lots of problems would never be found. A better solution would be to use a higher-level language so you don't have to worry about allocating and freeing memory, overrunning arrays, etc.
--Ben
Re:Dumb security question
by
jilles
·
· Score: 3, Insightful
The whole issue is not to use insecure languages like C. Such languages allow all sorts of memory manipulation and typically depends on the programmer to secure. The situation is made worse by the lack of something pretty essential: good libraries for string manipulation. While 3rd party libraries are available you can't assume these to be present so many developers still use char*.
Code reviews help, testing helps, good programming helps. But neither of these practices has succeeded in eliminating this type of bugs. It is just not good enough, witness a zillion bugs and security breaches on all major OSes (including the ones deemed secure, and yes I am talking about BSD) throughout the last decade. These OSes only differ in how the issues are dealt with. The occurance of the issue is a fact of life for all of them.
There's no C developer that can claim his program is completely free of buffer overflows (many foolishly do however). There may be some undetected errors in the program, the progrm may depend on third party code that contains bugs (e.g. the compiler or one of the standard libraries). Most likely bugs in all three categories are present.
Automatic checks are indeed the solution to the problem and modern languages build these checks into the run-time environment, where they belong. Buffer overflows are a non-issue in Java, for instance. The exception of this is native code and the JVM itself (written in C).
To eliminate buffer overflows, getting rid of the C legacy is the only solution. Java is probably too controversial as an alternative right now (though arguably it is quite up to the task as far as server side development is concerned) but there are other alternatives. Rebuilding serverside services like ftp, dns, ssh, smtp, pop, etc. is mandatory since each of these services has widely used C implementations that are frequently plagued by buffer overflows. The only way to guarantee that there are none left is to reimplement them.
--
Jilles
Re:Dumb security question
by
iabervon
·
· Score: 2
It would be possible to find occurences of known common mistakes in different packages automatically, and to find instances of a known error throughout a large project. There is work on doing this with the linux kernel, where a group has turned up hundreds of potentially unsafe usages (mostly DoS-type, mostly in drivers).
This particular problem is not actually a buffer overflow at all, it turns out, and is more subtle.
There are commercial programs which can find this sort of error, assuming it actually happens while running an instrumented version of the code. These programs are in the expensive commercial development tool price range (order $10k), though, and very difficult to write.
Another possibility is to build and run the program under a virtual machine which checks these things; for example, if you turn your C into Java and run it, it shouldn't throw any out-of-bounds exceptions, or it indicates that your C wasn't checking array bounds. There isn't a C virtual machine (that I know of), though.
It'd be next to impossible to detect a second free() of some chunk of code because machines are horrible at guessing what a programmer meant to do, rather than what they did. There are many tools available to diagnose memory problems, but they are slow and must be monitoring the code while it's running to do any good; to boot, they proabably won't find errors under normal program use. Besides, isn't this the C programmer's creed (the computer does what I tell it to do)? Well, zlib is doing exactly what the C programmer told it to do.
>the progrm may depend on third party code that contains bugs
.. or your 'non insecure language' runtime could contain bugs (as you point out.) At some point, the machine gets instructions, and while safe languages might cut down on the number of 'dumb' overflow bugs, the simple fact remains that overflow bugs will _always_ exist.
Education over technological safegaurds (I could just see the next generation of programmers: 'buffer what?').. otherwise, you rely on something you 'assume' is safe, but isn't neccessarily so.
All of this is notwithstanding the question: is a buffer overflow error in a platform that has 100% deployment better than lots of programs here and there getting their native buffer overflow bugs discovered? Interesting question unto itself...
Also, remember that performance requirements of core services (ftp, dns) have always outstripped performance supply. There will always be a need for languages that are 'closer to the cpu', in order to extract all possible performence to meet demand, and those will always be insecure.
Sure, client side run-once apps benifit greatly from safe languages, but there will always been a need for unsafe languages. To that end, I'd advocate pushing for a higher respect of 'safe' function use in code, by changing a developers' attitudes from 'ah, what the hell, i'm too lazy to use the safe func' to, 'if a safe func exists, use it or die'. Or writing safe wrappers to unsafe funcs, and having a policy saying you simply are not allowed to side-step the safe prototype.
I really can't imagine justifying the additional cost & perfornace hit of safe platforms with the laziness and 'infailability' of coders. If I were the one with my hands on the purse string, I'd understand that bugs will *always* exist (as to avoid putting all my proverbial eggs in one code base, which is probably the biggest problem facing our eceonomy's reliance in software stability and security), and make sure I have developers that understand how to minimize the possibility of producing code with these types of errors.
Also, don't forget.. a problem without a buffer overflow bug is still exploitable through a veritable infinitum of poor design choices, so are the benifits of nearly eliminating the possibility of buffer overflow bugs and memory related exploits truely worth the performance hit for critical systems with high load and a perf demand that almost always outstrips perf supply?
.. which is all a long winded way of saying, sure, your approach works for many cases, but it sounds like yet another case of someone with a hammer trying to make everything look like a nail.:)
-- "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!!!
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
UnknownSoldier
·
· Score: 2, Interesting
> Automatic checks are indeed the solution
Not for the embedded market, and consoles! I'm a console (games) programmer. All those little checks *ADD* up. Checks should be at the *programmer's descretion*, not at the whim of a compiler or language.
> to the problem and modern languages build these checks into the run-time environment, where they belong.
And you're completely ignoring the cost (performance) of doing so! For a debug build, yes, I love having extra checks, but for a full optimization build, NO. The performance cost is too high. There is a reason you have them in a debug build -- to write your code properly (robustfully) the 1st time, so you don't need the extra checking later.
> To eliminate buffer overflows, getting rid of the C legacy is the only solution.
Now you're trolling. You can write safe code in any language. Likewise you can write bad code in any language. Languages are *not* the silver bullet to the problem, but you for whatever reason think they are.
Insure (was Insight) does a tremendous job of this. I've been using Insure (used to be called Insight) for many years, and it can find all sorts of runtime problems. Of course, doing all the runtime checks is slow and takes time, but the savings in development time are awesome.
I am just a satisfied customer, and have no relationship with the company.
Re:Dumb security question
by
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
Kamel+Jockey
·
· Score: 2
So your second option, review/audit is a much better solution.
True, true. Never use a computer to do a human's job:)
-- In case of fire, do not use elevator. Use water!
Re:Dumb security question
by
iabervon
·
· Score: 2
The one of these I am familiar with does things with heap allocation, such that heap-allocated memory is separated by buffer zones of unallocated memory. This can be very helpful for checking bounds on accesses, but it won't catch everything.
First of all, it doesn't do anything with the stack, which is laid out by the program itself (with code generated by the compiler), and the most common buffer overruns are out of stack-allocated buffers into other parts of the same stack frame.
Similarly, it won't catch overruns of buffers in structs, where the overrun goes into adjacent fields but not out of the struct.
The essential problem is that nothing at runtime is keeping track of sizes of arrays and types of values, so incorrect usage cannot be detected. This information requires checks while running entirely non-library code, so it cannot be done by changing libraries.
Did this get released early? I got the RedHat advisory, but there is no source update at zlib.org, the CVE page at Mitre is empty and there is nothing from CERT yet.
What gives? Does anyone know where a patch is available?
--
Do you even know anything about perl? -- AC Replying to Tom Christiansen post.
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.
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
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
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
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.
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?)
Re:Version 1.1.4 fixes the problem
by
yem
·
· Score: 1
(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."
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ë
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
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
Tony+Hoyle
·
· Score: 2
As someone who has spent many hours staring at code trying to fix double-free bugs in Windows, I can definately say that it does *not* do any checking in release mode, and in debug it misses it half the time (usually failing a couple of minutes later on a completely unrelated allocation). If course the debug checking never gets used because anyone who wants to keep their sanity uses Purify anyway.
Therefore Windows is vulnerable. Applications aren't distributed with debugging enabled anyway (it's a license violation - gotta love closed source) so bleating 'there's checking in debug mode' is not helpful.
Should I upgrade my kernel?
by
uchian
·
· Score: 2
The article says that the kernel is affected - does it statically link zlib, in which case a recompile is in order, or do I just need to upgrade the zlib package?
Or is the article lying?
Re:Should I upgrade my kernel?
by
ceswiedler
·
· Score: 4, Interesting
The only dynamic linking the kernel uses is modules, which aren't used for providing library routines like zlib. The kernel does not link.so files. The code is almost certainly cut-and-pasted into the ppp compression code somewhere.
Re:Should I upgrade my kernel?
by
Mr+Z
·
· Score: 5, Informative
One place kernel uses zlib is to compress the kernel boot image. The kernel image then gets decompressed
during bootup. So, from the standpoint of "the kernel uses zlib", the kernel is affected.
There is, however, no new vulnerability introduced
as far as I can tell. To attack the zlib-based
decompression that the kernel performs, an attacker would need to modify the compressed kernel image that is used to boot the machine.
I can think of far more fruitful ways to
compromise a machine by modifying the kernel
image than by trying to dork the zlib decompression that happens before the kernel even runs.
Another place the kernel uses ZLib is when
mounting compressed filesystems. (Compressed
RAM disks and zisofs come to mind.) In this
case, you're asking a live kernel to decompress arbitrary data. These
are only issues when mounting untrusted media.
If you made the media yourself, then your
only risk is that corrupted media might cause
a kernel oops. And if you don't have cramdisk
and zisofs compiled in, you're safe.
Other places the kernel seems to use ZLib (from a cursory scan of the source -- there may be others):
jffs2 -- Journalling Flash Filesystem version 2
ppp -- used for ppp_deflate option
In any case, the kernel is a statically linked
entity, with a minor exception for modules.
ZLib is not a module, therefore to upgrade
ZLib in the kernel, you'll need to rebuild the
kernel. And it doesn't appear to be as easy as
just upgrading ZLib and rebuilding the kernel.
The kernel has multiple modified copies of ZLib
in its source tree. I'd wait for an official
kernel patch.
Is it just me, or have there been a really huge amount of security issues with Free/Open Source software this year?
It just seems like there's a new hole (or two) every week. Let's see, we've had openssh, zlib, php, mod_ssl, cvs, cups, rsync, exim, ncurses, glibc and more, just since January. We've still got two-thirds of the year to go. Anyone want to make bets on what other projects will get hit? I think we're going to see problems with XFree86, samba, and apache.
So, my question is this: Do you think that this is simply a bad time for FS/OSS security? Are we at the threshold where there are enough eyes on the code to locate these kinds of bugs? Or is the quality of FS/OSS declining?
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.
"...most of these bug postings are *theoretical* security flaws."
L0pht Heavy Industries: "Making the theoretical practical since 1992."
The fact is, a theoretical flaw is still a flaw, and it's still relevant to my original question.
"Many of these don't even have an exploit coupled with them..."
...yet.
"I guess the difference is that in a lot of these FS/OSS projects the potential problems are announced and stomped out quicker than they can become actual exploited vulnerabilities."
This is something that's been bugging me as well. It seems that more security bugs are kept quiet until a fix is prepared. Personally, I'd much rather know ASAP, so I can at least disable or filter the vulnerable service. I think that as soon as a vuln. is discovered & discussed on any public list, the more likely it will be that there is an exploit available. In some cases (WU-FTPd globbing bug comes to mind), the vuln. was known about for some time before the fix was available. In this case, there was even an exploit available. The bug was discovered in July, a security advisory was being drafted as early as September, and the fix didn't get released until December.
Its because buffer overflows are a hot topic now. Microsoft made them famous due to the exploits. Now everyone is quick to point them out and post them on their websites. I'd almost bet buffer overflow news in your favorite OS would get just as many hits as your favorite teen popstar naked. God knows I've done more searches this year for Red Hat and Windows bug errata than I have for Britney Spears' boobs.
As for the quality of free and open source software, well, I've never understood why people think it is any better than commercial software. I've been a professional programmer for 10 years and I've seen whack commercial code, whack open source code, and I'm pretty sure I've written some whack code myself. The license doesn't have much to do with it except for having NDA's keeping me from discussing some commercial code. Having open source visible on the bug watch list doesn't hurt much because fixes are usually available. Its when people don't pay attention to the fixes that the problem gets out of hand. Remember, the fix to the exploit that Code Red used was out a few weeks before Code Red. Now if we see this zlib bug take down a big chunk of the Linux communitiy in a few weeks then it will be a bad thing because we didn't pay attention.
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
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
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
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
Account+10
·
· Score: 2, Insightful
Wrong...
free(p);
free(p);
what happens if there is a thread switch between the two calls to free? Another thread can call malloc and receive the same value 'p' back.
When we switch back to this thread, it will free memory another thread still thinks it owns.
Calling free() twice on the same pointer is never safe.
Re:zlib rarely used in MacOS. MacOS safe.
by
yeOldeSkeptic
·
· Score: 2, Interesting
I hate to send rain on your parade but...
No command shell. No shell means no way to hook or intercept...
A command shell is just a convenient way to go around a UNIX system
after you've logged in. It has nothing to do with the question of
a box being easier to crack. Once you've been compromised, you've
been compromised --- whether you have a shell or not.
All mac developers know their code is always running at
root. Nothing is higher...
By always being root their is no false sense of security.
Tell that to the hapless windows user. Everyone is root there,
that didn't make windows more secure. Being root all the time
only means that when you have executed an email worm, it is trivial
for the worm to do anything it wants. The only reason Macs were'nt affected
by the ILOVEYOU virus is because Macs are not running visual basic.
Pascal strings...
are faster than C (because they have the length
delimiter in the front...
Which means I have only to change that
single number and I'll have what amounts to a buffer overran. Especially
if...
...
The Mac places return address infront of where the buffer would overrun.
Much safer.
Placing the return address in front of a buffer rather than at
the end is safer but does not guarantee that the machine won't be
compromised. Why?
Assume there is a function a() which calls b()
sometime after being invoked. In the Mac architecture, the return
address for a() is placed between buffer allocations for a()
and buffer allocations for b(). If the buffer allocated by a()
is globally accessible, then it is possible for some routine
c() to access that buffer, overrun the return address,
and have arbitrary code executed when b() returns. Granted, this
is more difficult to do than is the case with the intel architecture
but it is entirely possible. Having a different way of storing
return addresses is not a substitute for careful, paranoid programming.
Macs never run code ever merely based on how a file is named....
And so do Unix. The Mac style is even more readily compromised if
as you say, "A mac cannot run a program unless it has TWO files."
One of which is invisible. Imagine that!
You have a file that
cannot be seen by the ordinary user or by the standard file tools
provided by default. What would happen if someone (could
be you running a trojanned program) changes those so called ``hidden
attributes?'' (Discussion left as an exercise for the student.)
There are less macs,...
This is the real reason there are no Mac related compromises
on Bugtraq or anywhere. There are so few of them it just isn't
worth it for the script kids. But what kind of advertisement for
security is that? Mac Proven Safer because Unpopular and
Slow-Selling!
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
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 ?
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?
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?
-- 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
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.
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.
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.
This is obviously the work of Microsoft's Counter Intelligence Program!
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
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
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.
Re:Version 1.1.4 fixes the problem
by
BlowCat
·
· Score: 2
No, it's not the site, it's the poster who is suffering from the/. effect (actually, syndrome). The/. syndrome is: post as fast as possible and get tons of karma from moderators who don't check the links.
This is why you clear pointers after freeing them
by
coyote-san
·
· Score: 5, Informative
This is why you ALWAYS set a pointer to NULL after freeing it, even if it's "totally unnecessary" because you're about to free the structure holding the pointer.
This doesn't prevent attempts to free the previously freed pointer, but that will generally do a lot less damage than freeing a real malloc'd address. And during development it's trivial to add an assertion checking for a NULL pointer before any free().
-- For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
...shame on the distribution publishers.
by
yerricde
·
· Score: 2
Yet why in the name of all that is good do they not realize that C is an inherently unsafe language. There are some really good free alternatives to C, so why the heck are those numbskulls not using them?
Because most distributions of GNU/Linux operating systems don't install any compiled languages but C and C++. (There is no language called "C/C++".)
Because popular libraries have C bindings.
Because compilers can optimize C code for machines with limited resources. (Java technology is a memory hog partly because of the 16-byte overhead of java.lang.Object.)
Because people think in "step 1, step 2, step 3" of an algorithm, rther thn in functionl style (partially ruling out CL, ML, and Haskell).
Take your choice: Eiffel, Ada, Modula-3
Which of these languages is in the default devel install in all the major distros and can link to libraries' C bindings?
Don't know (was hoping that someone on this board knew that).
And are those the ONLY things that EVER run on that box?
Now that you mention it on I also run sshd and mysql (on 127.0.0.1 no remote access)
-- I know I'm going to hell, I'm just trying to get good seats.
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
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.
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
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.
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.
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.
I set that up the first day that the ads started showing up. I couldn't figure out what the parent post was about until you said that.
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.
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.
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?
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:This is why you clear pointers after freeing th
by
greed
·
· Score: 3, Informative
Calling free() on a NULL pointer is a no-op. No check or assertion is needed.
The assertion lets you catch the logic error that led to the second free during debugging. Presumably, your code path wasn't expecting the pointer to already be free at that point; otherwise, you would have designed it to handle that case already.
Then, in production code, if you do take that path, you'll get the harmless no-op free(0). (You do build production with -DNDEBUG, right?)
Re:So much for "many eyes"....
by
jgerman
·
· Score: 2
Don't mistake tasteful discretion for tyrannical repression, it'll only make you paranoid.
Did you come up with that one? Well put. I may have to make that my sig, I feel the same way, wish I had thought up that one.;)
-- I'm the big fish in the big pond bitch.
Count based on advisory at SecurityFocus
by
sterno
·
· Score: 2
My count of 20 packages is based on the warning redhat distributed. They recommend upgrading some 22 packages on a Redhat 7.2 system. This includes several packages for the kernel, zlib itself, and a number of other applications that are statically linked such as cvs, dump, etc.
The scary thing is, I may have installed other apps that have zlib statically compiled that I don't even know about because they aren't part of the default vendor distribution.
--
This sig has been temporarily disconnected or is no longer in service
Re:Count based on advisory at SecurityFocus
by
MSG
·
· Score: 2
They recommend upgrading some 22 packages on a Redhat 7.2 system.
Most of those packages are related to gcc3 and vnc, which you probably don't have installed. Leave off those two, and you have about 6 or 7 updates left, including the zlib package.
This includes several packages for the kernel...
Actually, kernel 2.4 is absent from the list of updates.
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.)
On Linux : add this at the beginning of your/etc/rc file and in your shell init scripts:
export MALLOC_CHECK_=2
(don't forget the extra underscore at the end).
On BSD systems:
ln -s ZH/etc/malloc.conf
It will protect both your statically and dynamically linked apps. It adds a little performance penalty, but it's really not noticeable.
-- {{.sig}}
Re: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:That's better
by
Geekboy(Wizard)
·
· Score: 2, Insightful
The TCP stack for almost all OS's was {stolen|borrowed|based on} the TCP stack in BSD 4.x (IIRC). I remember once, a few years ago, a system engineer did a special sequence on a Windows 98 computer, and got the BSD copyright to show up.
VM in Linux is a mess. 2 (very) different VM systems, that cause quite a few utilities to be re-writtian. All of the BSD's have one each, and they optimize their VM quite well. FreeBSD has a very robust one, that is a bit slower than Linux's, but seems to be more stable.
OpenBSD just got statefull firewall with the latest version (3.0) Prior to that, they were using Darren Reed's IPF, but due to a licensing fiasco (and petty name calling), IPF was yanked, and PF was created. I use PF in my firewall at home, and I am quite happy. I can't wait until 3.1 (not willing to run -current) to see how much more robust it can get. =)
Re:This is why you clear pointers after freeing th
by
istartedi
·
· Score: 2
Problem: What if you have a structure that *optionally* allocates memory, and your cleanup code for that structure just frees all the pointers?
I have never bothered to check free because my rule is: for every init of a structure, make sure you call the cleanup.
This has worked for hundreds of kLOC of C I've written. Also, debugging heaps are nice.:)
-- For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
Re:OFF TOPIC! LARGER ADS!
by
mirabilos
·
· Score: 1
Lynx.
-- My Karma isn't excellent, damn it! (And/. still does not get UTF-8 right in 2012. Wow.)
Because when closed source software (not limited to just MS) has a security bug it was found because somebody managed to exploit it. When you find bugs in open source software you don't have to find them with an exploit, you can find them with your eyes.
Remote upgrades : be careful
by
chrysalis
·
· Score: 3, Insightful
If you have to remotely upgrade the zlib library, be *very careful*.
Because SSH/OpenSSH depend on zlib, if you replace your current libz.so file with another version whoose API has a bit changed, your SSH server won't work any more.
So if you don't have access to the console, open a classical 'telnet' port for a few minutes, just during the upgrade. Once you've checked that SSH is still ok, you can remove the telnet daemon.
If SSH doesn't work any more after the zlib upgrade, recompile SSH.
-- {{.sig}}
Re:Remote upgrades : be careful
by
Electrum
·
· Score: 4, Informative
So if you don't have access to the console, open a classical 'telnet' port for a few minutes, just during the upgrade. Once you've checked that SSH is still ok, you can remove the telnet daemon.
Since the SSH server forks after you've connected, you can safely stop the server while connected via SSH. You never need to use telnet. Just make sure that you can still connect before disconnecting from the original SSH connection.
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.)
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.
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.
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.;-)
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.
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..
> 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: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.
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."
Not both directions. That's the part that bugs greatly. PF now has the both direction stateful.
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.
If the strength of Linux is closing the barn doors after the horses have ran amok, I think I'll investigate BSD, where they, you know, actively audit the code.
Perhapse you'd like to catch up on recent events with OpenSSH? Yes. The one from OpenBSD.
Yes, if security is your main concern, one should consider OpenBSD. And their creating of OpenSSH is a great service towards the entire open source (heck - IT / infosec) community. But lets not use it in a lame attempt at a flame war.
Would be impossible in garbage-collected language!
by
Tom7
·
· Score: 5, Interesting
Like most recent security holes in linux software, this one would be unexploitable in a modern safe language. (In fact it would be *impossible* to make this error in a garbage-collected language!)
The typical response I hear to this kind of comment is that "high level languages are inefficient". (I don't belive this is true, but most other people here do.) But whatever, let's pretend they are.
Now, what kind of crazy world do we live in where we value performance more than correctness (security)?? We are seeing more and more security holes as we try to write bigger and bigger packages in C. Why do we accept this? Who here really cares more about the performance of zlib than the time it takes for them to patch all of their statically-linked software, and their risk of being rooted until they do? I sure don't.
Forget about all this "coding practices" stuff. It simply takes too much effort to produce bug-free code in C. The OpenBSD people, kings of code review, just had an exploitable bug in sshd! While we need to use C for some tasks (ie, most parts of the kernel), I think we are seriously unpowered to do this for most applications (as evidenced by the high number of simple errors made, and sometimes caught).
If we simply wrote our software in high level languages, we would automatically rule out the largest classes of security holes, which would give us a lot more time to work on more important things, like high level architecture review and optimizations. I think we'd end up with a better system. So what's keeping us?
Open Source does not mean it's actually reviewed!
by
Tom7
·
· Score: 2
Unfortunately, most code isn't reviewed (or if it is, it's not reviewed carefully). I think it's just a myth that openness implies more review. (One might even make the argument that openness causes laziness!)
In fact, the very first piece of linux code I looked at carefully (the MD5_crypt code in PAM) had some very obvious mistakes in it. Anyone actually auditing it should have noticed it. And this is a highly security-critical piece of code!
I'm not saying that open source doesn't have its benefits (it certainly does), but simply making something open doesn't make the code better. People have to actually review it, and they seldom do.
The original TCP/IP stack was BSD's. This has been completely rewritten multiple times since then.
I suspect that at one time in the past, BSD's VM was the Linux VM, until a rewrite occurred.
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.
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.
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.
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
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
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).
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.
like previously native heap corruption bug in glibc-glob.c. no doubt there are string of embarrassing security glitches still to be found.
Re:That's better
by
red5
·
· Score: 2, Informative
No, one they stole, one they wrote themselves.
Linux didn't steal shit otherwise someone would post some code comparissions by now. It's not exacly hard to get the code (There both free for download).
So my message to you trolls is put up or shut up.
I want to see proof showing that the code used in the linux kernel was copyed from BSD.
Until then go fuck you self.
-- I know I'm going to hell, I'm just trying to get good seats.
Re:Would be impossible in garbage-collected langua
by
Tom7
·
· Score: 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: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:Would be impossible in garbage-collected langua
by
jonabbey
·
· Score: 2
Re:It should be a warning
by
Panaflex
·
· Score: 2
My tips:
* Use electric Fence (Read the FAQ.. there's several levels of checking) * memprof is nice * When you free(), I always use a macro like so.. #define FREE free(x);x=NULL * You can use the glib memory management as well, though there are some annoyances. But you get some freebie implementations of list, hash,sort, etc functions.
That way you get a nice clean segfault:-)
Enjoy the show.
Pan
-- I said no... but I missed and it came out yes.
Re:Would be impossible in garbage-collected langua
by
Tom7
·
· Score: 2
An AC
> Go to the functional programming contest site and look at the timings of the winning > entries and the language they are written in. The last contest was "compressing" a > hypothetical HTML-like markup language. The C++ entries ran in a few seconds, whereas the > O'Camel entries took several minutes to complete.
I competed in this contest, and I'm quite familiar with it and the performance of the various entries. (In fact, our Non-C entry placed 9th overall.) The performance of Non-C languages was very good in this contest. Anyway, the best one was written in Haskell, and that's because it had the best algorithm. Did you totally overlook this? I don't understand where you're getting these numbers from.
Of course, most of the C and C++ entries didn't even work.
Why are you posting anonymously?
Re:Gah! Stop this stupid argument!
by
jilles
·
· Score: 2
IMHO 95% of C development because of performance reasons is not based on any factual evidence for performance gains. I've noticed people use C just to be sure rather than that they are experiencing actual performance problems. To make things worse: there appear to be a lot of myths about performance and most C programmers I've seen are rather stubborn and not particularly sensitive to perfectly good argumentation.
Also there are much more safe languages than C that can be just as fast as C. Somebody already mentioned ADA, lets also mention Eiffel. Not using those in system that needs to be secure is almost criminal given the near certainty of buffer overflows.
Once again, I have seen http servers, mail servers, ldap servers written in 100% Java performing at a very acceptable level. I too would like to see fast implementations of zlib, I don't see how this cannot be done in another language than C.
Maybe 1% of the code actually requires some of the dirty trickery in C (I'm very sceptical of this need) but that doesn't mean you need to implement the other 99% of the code in C as well.
You list a few interpreted and just in time compiled languages. It is commonly known that these are slower than compiled languages than C (even though they are getting awfully close performance wise). However you can do stuff like bounds checking and garbage collection in statically compiled languages as well.
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.
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.
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.
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: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)
Re:Would be impossible in garbage-collected langua
by
Tom7
·
· Score: 2
> Step back and think a moment about what you just said. Garbage collection makes no > guarentees about when GC will actually occurs. That means every time kalloc was called, > there would be the potential for it to sleep while the GC searched the reference tree. > This is absolutely no good for the kernel.
Actually, there are several real-time garbage collectors around. It's not at all impossible to have a real-time one with low overhead (lower than certain mallocs), and still win in terms of ease of use, correctness, and heap compaction. Don't forget that malloc implementations also need to do things like coalescing that can cause an alloc or free to "sleep" (that is, take a while) too!
Anyway, I wasn't *really* suggesting retrofiting linux with a garbage collector. They already do a pretty good job of memory management. I'm just saying that for a new kernel, the idea of GC is not so preposterous. Not all garbage collectors act like emacs lisp or the JVM.
> The zlib_inflate and zlib_deflate routines do not call malloc()/free()
This is interesting. If so, then how can the kernel be subject to this double-free bug? (Some people were claiming that.)
> Compression/Decompression is inherently a costly operation. It fortunately though is not > one that requires a great deal of allocation/deallocation. Therefore, there is no > justification for adding the overhead of a complex memory tracking system.
I don't think this follows. You mean overhead in terms of complexity or in terms of run-time? If it doesn't do much allocation, then (supposing the garbage collector imposes a significant performance hit) it will not be impacted much by a garbage collector. If you are talking about code complexity, well, it would certainly be overkill to implement a garbage collector just for that one library, but I'm not suggesting that. I'm suggesting that we use high level languages where possible, particularly ones with garbage collectors -- in this case it SIMPLIFIES the code. In fact, here it would remove a potentially exploitable bug.
> Besides, as many posters pointed out, there is a mechanism in LIBC to allow memory to be > tracked dynamically. The performance trade off is just not exceptable though. So called > high level languages are not the solution to every problem.
It's not fair to compare the performance of debugging LIBC calls to the performance of an optimized safe high-level language. But either way, I don't think any "tradeoff" that sacrifices correctness for speed is really a "tradeoff", it's just a mistake.
Re:Would be impossible in garbage-collected langua
by
lkaos
·
· Score: 2
Actually, there are several real-time garbage collectors around. It's not at all impossible to have a real-time one with low overhead (lower than certain mallocs), and still win in terms of ease of use, correctness, and heap compaction. Don't forget that malloc implementations also need to do things like coalescing that can cause an alloc or free to "sleep" (that is, take a while) too!
malloc/free are _not_ used in the kernel. The kernel doesn't really have VM in the traditional sense. Garbage collection works when you have an underlying VM because unused memory is swapped to disk and therefore has no real performance penality. So, if a GC holds on to 50MB of unused memory, so what? It will get swapped to disk.
No so in the kernel though. It is vitally important that memory be free'd as soon as it can so that more RAM is available to applications. Now, having a VM in the kernel would not solve the problem because there would be a performance nightmare if kernel code had to be swapped in from disk.
I'm suggesting that we use high level languages where possible
The only area I disagree with you is on whether it is possible to use a high level language in the kernel. I do not believe it is. Now, with a microkernel, things are a bit different because there is a much more vague line between what is and isn't the kernel so there may be room for arguement there, but for the standard monolithic kernel, high level code just has to much overhead to be effective.
But either way, I don't think any "tradeoff" that sacrifices correctness for speed is really a "tradeoff", it's just a mistake.
What is truely needed is a mechanism to perform allocation/deallocation during compile time instead of run time. A mechanism to determine when a pointer is no longer valid and then inserts a deallocation within the code at that point. Solving poor programming during run-time is just a bad idea.
--
int func(int a);
func((b += 3, b));
Re: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.
--
int func(int a);
func((b += 3, b));
Re:It should be a warning
by
Panaflex
·
· Score: 2
libglib can be compiled with rudamentary mem checking. (See g_mem_profile and g_mem_check).I've also found that using glib sometimes makes memprof much happier than malloc/free. Memprof does not like openssl though! Pan
-- I said no... but I missed and it came out yes.
Re:It should be a warning
by
Panaflex
·
· Score: 2
My macro works fine thanks. Yes, I am aware of ways in which it will not work but c'est la vie.
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.)
Slashdot Mirror
could somebody point out where in the source this is? the article was fluff.
https://www.accountkiller.com/removal-requested
This article gives more information, and links to vendor advisories: http://www.linuxsecurity.com/articles/security_sou rces_article-4582.html.
-mark
If your computer says LINUX, run...computers can't talk! [unless you have text-speech software]
Some More Links.
zlib is not os dependent. Many Windows based products/projects use it as well. Is there some linux specific issues related to this overflow issue?... or is it just a headline hype thing
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ë
Owen Taylor at RedHat found the bug. He works on GTK among other things, as you can see from the GTK+ release notes he posted earlier this month: mail.gnome.org/archives/gtk-devel-list/2002-March/ msg00161.html
http://tinyurl.com/4ny52
On the stuff I've been reading about finding and fixing buffer overflows, it seems like it's generally not too hard to spot where these things could potentially happen.
My question is this: How feasible would it be for someone to take a computer and have it do nothing but pattern-matching through all the source code in a typical Linux distribution, looking specifically for problem areas like these? Obviously we couldn't rely on it as a foolproof audit, but has something like this ever been considered?
--------
Bleah! Heh heh heh... BLEAH BLEAH!!! Ha ha ha ha...
The advisory for zlib-1.1.3 is at:
i b Advisory 2002-03-11
1 .4 .tar.gz
http://www.zlib.org/advisory-2002-03-11.txt
Zl
zlib Compression Library Corrupts malloc Data Structures via Double Free
The new zlib (1.1.4) is at:
ftp://ftp.info-zip.org/pub/infozip/zlib/zlib-1.
Did this get released early? I got the RedHat advisory, but there is no source update at zlib.org, the CVE page at Mitre is empty and there is nothing from CERT yet.
What gives? Does anyone know where a patch is available?
Do you even know anything about perl? -- AC Replying to Tom Christiansen post.
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.
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?
Here is some more linkage to the navagationally impared.
ASCII tastes bad dude.
Binary it is then.
And the site seems to be suffering from the /. effect. Either that or they didn't patch and someone took advantage of the exploit.
STOP MISUSING APOSTROPHES, YOU MORONS!!!
Duplicate deletions are not the same as buffer overflows and are no where near as easy to exploit. In fact, I have _never_ seen a duplicate deletion exploitation other than a simple DoS. Not to mention the fact that it requires a special series of calls from the calling program.
In summary, the world hasn't come to an end and Free Software is all-the-sudden as vunerable as closed source software. Put the pills down and relax
int func(int a);
func((b += 3, b));
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?)
Wrong URL. Try here.
No, I did not read the f***ing article!
Woops:
http://www.gzip.org/zlib
and the advisory on their site.
(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."
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ë
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.
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
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 ?
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?
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... :(
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
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.
This is obviously the work of Microsoft's Counter Intelligence Program!
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?
No, it's not the site, it's the poster who is suffering from the /. effect (actually, syndrome). The /. syndrome is: post as fast as possible and get tons of karma from moderators who don't check the links.
This is why you ALWAYS set a pointer to NULL after freeing it, even if it's "totally unnecessary" because you're about to free the structure holding the pointer.
This doesn't prevent attempts to free the previously freed pointer, but that will generally do a lot less damage than freeing a real malloc'd address. And during development it's trivial to add an assertion checking for a NULL pointer before any free().
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
Yet why in the name of all that is good do they not realize that C is an inherently unsafe language. There are some really good free alternatives to C, so why the heck are those numbskulls not using them?
Because most distributions of GNU/Linux operating systems don't install any compiled languages but C and C++. (There is no language called "C/C++".)
Because popular libraries have C bindings.
Because compilers can optimize C code for machines with limited resources. (Java technology is a memory hog partly because of the 16-byte overhead of java.lang.Object.)
Because people think in "step 1, step 2, step 3" of an algorithm, rther thn in functionl style (partially ruling out CL, ML, and Haskell).
Take your choice: Eiffel, Ada, Modula-3
Which of these languages is in the default devel install in all the major distros and can link to libraries' C bindings?
Will I retire or break 10K?
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!
Doesn't proftpd do zlib like wuftpd does?
Don't know (was hoping that someone on this board knew that).
And are those the ONLY things that EVER run on that box?
Now that you mention it on I also run sshd and mysql (on 127.0.0.1 no remote access)
I know I'm going to hell, I'm just trying to get good seats.
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
Just right click on the image "Block images from this server". Et voila!
Ah, may be you do not use mozilla ?
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"
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.
If they ripped them off as you say they would not be able to licence them as GPL now could they?
sure they could. The BSD license lets anyone do whatever they want, including relicense the code as GPL. There is already BSD code in the Linux kernel.
cpeterso
The 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.
I set that up the first day that the ads started showing up. I couldn't figure out what the parent post was about until you said that.
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.
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.
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?
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.
The assertion lets you catch the logic error that led to the second free during debugging. Presumably, your code path wasn't expecting the pointer to already be free at that point; otherwise, you would have designed it to handle that case already.
Then, in production code, if you do take that path, you'll get the harmless no-op free(0). (You do build production with -DNDEBUG, right?)
Did you come up with that one? Well put. I may have to make that my sig, I feel the same way, wish I had thought up that one.
I'm the big fish in the big pond bitch.
My count of 20 packages is based on the warning redhat distributed. They recommend upgrading some 22 packages on a Redhat 7.2 system. This includes several packages for the kernel, zlib itself, and a number of other applications that are statically linked such as cvs, dump, etc.
The scary thing is, I may have installed other apps that have zlib statically compiled that I don't even know about because they aren't part of the default vendor distribution.
This sig has been temporarily disconnected or is no longer in service
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
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}}
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
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.
#define NULL 5
while(1)
{
if (x=*NULL)
break;
}
The TCP stack for almost all OS's was {stolen|borrowed|based on} the TCP stack in BSD 4.x (IIRC). I remember once, a few years ago, a system engineer did a special sequence on a Windows 98 computer, and got the BSD copyright to show up.
VM in Linux is a mess. 2 (very) different VM systems, that cause quite a few utilities to be re-writtian. All of the BSD's have one each, and they optimize their VM quite well. FreeBSD has a very robust one, that is a bit slower than Linux's, but seems to be more stable.
OpenBSD just got statefull firewall with the latest version (3.0) Prior to that, they were using Darren Reed's IPF, but due to a licensing fiasco (and petty name calling), IPF was yanked, and PF was created. I use PF in my firewall at home, and I am quite happy. I can't wait until 3.1 (not willing to run -current) to see how much more robust it can get. =)
Problem: What if you have a structure that *optionally* allocates memory, and your cleanup code for that structure just frees all the pointers?
I have never bothered to check free because my rule is: for every init of a structure, make sure you call the cleanup.
This has worked for hundreds of kLOC of C I've written. Also, debugging heaps are nice. :)
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
Lynx.
My Karma isn't excellent, damn it! (And
Because when closed source software (not limited to just MS) has a security bug it was found because somebody managed to exploit it. When you find bugs in open source software you don't have to find them with an exploit, you can find them with your eyes.
Matt. Want XML + Apache + Stylesheets? Get AxKit.
If you have to remotely upgrade the zlib library, be *very careful* .
Because SSH/OpenSSH depend on zlib, if you replace your current libz.so file with another version whoose API has a bit changed, your SSH server won't work any more.
So if you don't have access to the console, open a classical 'telnet' port for a few minutes, just during the upgrade. Once you've checked that SSH is still ok, you can remove the telnet daemon.
If SSH doesn't work any more after the zlib upgrade, recompile SSH.
{{.sig}}
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
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.
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.
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.
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.
Windows, Smart? What bullshit, unless things have changed since 98. I've written programs that did the double free thing and never saw an error message other than my or some other program freezing up. With all the "uber-patches" and what not M$ needs monthly, I just don't think that is so.
The only insecure thing I do with my home network is use a windows machine at work to log into it. Apt-get update and upgrade, all fixed in ten minutes before I go home. I'm going to have to call the folks at Red Hat to figure out up2date when I get home, sigh. The M$ box that I have to use for cameras and a scanner? It's blind to the network and usually runs Red Hat. IE? Eye-EEEEEeeee!
Friends don't help friends install M$ junk.
Sorry, I must have gotten confused with all those viruses like code red, nimida, sircam, and countless minor expoits for M$ OS. Ha Ha!
Friends don't help friends install M$ junk.
I dunno, most double frees come from freeing DIFFERENT copies of a pointer. Setting one to NULL won't help in this case...
;))
(A much better solution is to use a garbage collector.
In a recent reverse engineering session, I noticed that Internet Explorer uses zlib! myria
"Screw Sun, cross-platform will never work. Let's move on and steal the Java language." - Visual J++ Product Manager
Cool but it still bugs me when people say Linux just stole it's TCP/IP, VM etc from BSD.
They never offer any evidance of it and all it serves to do is belittle the efferts of the linux community.
I understand that these people don't represent the BSD community. It's still anoying though.
I'm verry thankfull for what Linux/GNU has given me for free.
how else would a kid like me get access to UNIX a C compiler etc.
And if the BSD community supplied any of that they diserve there props too.
But the guy didn't have to be a dick about it is all I'm trying to say .
I know I'm going to hell, I'm just trying to get good seats.
>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...
Ummm, ipf is/was stateful as well. OpenBSD has always had a stateful packet filter.
Not both directions. That's the part that bugs greatly. PF now has the both direction stateful.
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.
Perhapse you'd like to catch up on recent events with OpenSSH? Yes. The one from OpenBSD.
Yes, if security is your main concern, one should consider OpenBSD. And their creating of OpenSSH is a great service towards the entire open source (heck - IT / infosec) community. But lets not use it in a lame attempt at a flame war.
Like most recent security holes in linux software, this one would be unexploitable in a modern safe language. (In fact it would be *impossible* to make this error in a garbage-collected language!)
The typical response I hear to this kind of comment is that "high level languages are inefficient". (I don't belive this is true, but most other people here do.) But whatever, let's pretend they are.
Now, what kind of crazy world do we live in where we value performance more than correctness (security)?? We are seeing more and more security holes as we try to write bigger and bigger packages in C. Why do we accept this? Who here really cares more about the performance of zlib than the time it takes for them to patch all of their statically-linked software, and their risk of being rooted until they do? I sure don't.
Forget about all this "coding practices" stuff. It simply takes too much effort to produce bug-free code in C. The OpenBSD people, kings of code review, just had an exploitable bug in sshd! While we need to use C for some tasks (ie, most parts of the kernel), I think we are seriously unpowered to do this for most applications (as evidenced by the high number of simple errors made, and sometimes caught).
If we simply wrote our software in high level languages, we would automatically rule out the largest classes of security holes, which would give us a lot more time to work on more important things, like high level architecture review and optimizations. I think we'd end up with a better system. So what's keeping us?
For more discussion, see our big argument in the story about the OpenSSH root hole. http://slashdot.org/comments.pl?sid=29123&cid=3124 957
Unfortunately, most code isn't reviewed (or if it is, it's not reviewed carefully). I think it's just a myth that openness implies more review. (One might even make the argument that openness causes laziness!)
In fact, the very first piece of linux code I looked at carefully (the MD5_crypt code in PAM) had some very obvious mistakes in it. Anyone actually auditing it should have noticed it. And this is a highly security-critical piece of code!
I'm not saying that open source doesn't have its benefits (it certainly does), but simply making something open doesn't make the code better. People have to actually review it, and they seldom do.
The original TCP/IP stack was BSD's. This has been completely rewritten multiple times since then.
I suspect that at one time in the past, BSD's VM was the Linux VM, until a rewrite occurred.
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.
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.
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.
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
Sure about that? I've been doing
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?
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
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).
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.
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.
> 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!)
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..
Only four times?
- jon
Ganymede, a GPL'ed metadirectory for UNIX
My tips:
:-)
* Use electric Fence (Read the FAQ.. there's several levels of checking)
* memprof is nice
* When you free(), I always use a macro like so..
#define FREE free(x);x=NULL
* You can use the glib memory management as well, though there are some annoyances. But you get some freebie implementations of list, hash,sort, etc functions.
That way you get a nice clean segfault
Enjoy the show.
Pan
I said no... but I missed and it came out yes.
An AC
> Go to the functional programming contest site and look at the timings of the winning
> entries and the language they are written in. The last contest was "compressing" a
> hypothetical HTML-like markup language. The C++ entries ran in a few seconds, whereas the
> O'Camel entries took several minutes to complete.
I competed in this contest, and I'm quite familiar with it and the performance of the various entries. (In fact, our Non-C entry placed 9th overall.) The performance of Non-C languages was very good in this contest. Anyway, the best one was written in Haskell, and that's because it had the best algorithm. Did you totally overlook this? I don't understand where you're getting these numbers from.
Of course, most of the C and C++ entries didn't even work.
Why are you posting anonymously?
IMHO 95% of C development because of performance reasons is not based on any factual evidence for performance gains. I've noticed people use C just to be sure rather than that they are experiencing actual performance problems. To make things worse: there appear to be a lot of myths about performance and most C programmers I've seen are rather stubborn and not particularly sensitive to perfectly good argumentation.
Also there are much more safe languages than C that can be just as fast as C. Somebody already mentioned ADA, lets also mention Eiffel. Not using those in system that needs to be secure is almost criminal given the near certainty of buffer overflows.
Once again, I have seen http servers, mail servers, ldap servers written in 100% Java performing at a very acceptable level. I too would like to see fast implementations of zlib, I don't see how this cannot be done in another language than C.
Maybe 1% of the code actually requires some of the dirty trickery in C (I'm very sceptical of this need) but that doesn't mean you need to implement the other 99% of the code in C as well.
You list a few interpreted and just in time compiled languages. It is commonly known that these are slower than compiled languages than C (even though they are getting awfully close performance wise). However you can do stuff like bounds checking and garbage collection in statically compiled languages as well.
Jilles
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.
For those who don't have that option, you could try editing your host file:
For Windows 9x:
start->run
notepad c:\windows\hosts
Add
0.0.0.0 ad.doubleclick.net
And so on.
Or if you want to see your own custom pictures instead, change the address to point to a custom webserver and script.
Have fun!
Link.
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
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.
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
libglib? Surely you jest...
My Karma isn't excellent, damn it! (And
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)
> Step back and think a moment about what you just said. Garbage collection makes no
> guarentees about when GC will actually occurs. That means every time kalloc was called,
> there would be the potential for it to sleep while the GC searched the reference tree.
> This is absolutely no good for the kernel.
Actually, there are several real-time garbage collectors around. It's not at all impossible to have a real-time one with low overhead (lower than certain mallocs), and still win in terms of ease of use, correctness, and heap compaction. Don't forget that malloc implementations also need to do things like coalescing that can cause an alloc or free to "sleep" (that is, take a while) too!
Anyway, I wasn't *really* suggesting retrofiting linux with a garbage collector. They already do a pretty good job of memory management. I'm just saying that for a new kernel, the idea of GC is not so preposterous. Not all garbage collectors act like emacs lisp or the JVM.
> The zlib_inflate and zlib_deflate routines do not call malloc()/free()
This is interesting. If so, then how can the kernel be subject to this double-free bug? (Some people were claiming that.)
> Compression/Decompression is inherently a costly operation. It fortunately though is not
> one that requires a great deal of allocation/deallocation. Therefore, there is no
> justification for adding the overhead of a complex memory tracking system.
I don't think this follows. You mean overhead in terms of complexity or in terms of run-time? If it doesn't do much allocation, then (supposing the garbage collector imposes a significant performance hit) it will not be impacted much by a garbage collector. If you are talking about code complexity, well, it would certainly be overkill to implement a garbage collector just for that one library, but I'm not suggesting that. I'm suggesting that we use high level languages where possible, particularly ones with garbage collectors -- in this case it SIMPLIFIES the code. In fact, here it would remove a potentially exploitable bug.
> Besides, as many posters pointed out, there is a mechanism in LIBC to allow memory to be
> tracked dynamically. The performance trade off is just not exceptable though. So called
> high level languages are not the solution to every problem.
It's not fair to compare the performance of debugging LIBC calls to the performance of an optimized safe high-level language. But either way, I don't think any "tradeoff" that sacrifices correctness for speed is really a "tradeoff", it's just a mistake.
Actually, there are several real-time garbage collectors around. It's not at all impossible to have a real-time one with low overhead (lower than certain mallocs), and still win in terms of ease of use, correctness, and heap compaction. Don't forget that malloc implementations also need to do things like coalescing that can cause an alloc or free to "sleep" (that is, take a while) too!
malloc/free are _not_ used in the kernel. The kernel doesn't really have VM in the traditional sense. Garbage collection works when you have an underlying VM because unused memory is swapped to disk and therefore has no real performance penality. So, if a GC holds on to 50MB of unused memory, so what? It will get swapped to disk.
No so in the kernel though. It is vitally important that memory be free'd as soon as it can so that more RAM is available to applications. Now, having a VM in the kernel would not solve the problem because there would be a performance nightmare if kernel code had to be swapped in from disk.
I'm suggesting that we use high level languages where possible
The only area I disagree with you is on whether it is possible to use a high level language in the kernel. I do not believe it is. Now, with a microkernel, things are a bit different because there is a much more vague line between what is and isn't the kernel so there may be room for arguement there, but for the standard monolithic kernel, high level code just has to much overhead to be effective.
But either way, I don't think any "tradeoff" that sacrifices correctness for speed is really a "tradeoff", it's just a mistake.
What is truely needed is a mechanism to perform allocation/deallocation during compile time instead of run time. A mechanism to determine when a pointer is no longer valid and then inserts a deallocation within the code at that point. Solving poor programming during run-time is just a bad idea.
int func(int a);
func((b += 3, b));
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));
libglib can be compiled with rudamentary mem checking. (See g_mem_profile and g_mem_check).I've also found that using glib sometimes makes memprof much happier than malloc/free. Memprof does not like openssl though!
Pan
I said no... but I missed and it came out yes.
My macro works fine thanks. Yes, I am aware of ways in which it will not work but c'est la vie.
My main concern is instances of the following.
buf = malloc(BUFLEN);
do stuff..
if (!x) FREE(buf);
if(buf) {
blah;
FREE(buf);
}
Pan
I said no... but I missed and it came out yes.
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