Zlib Security Flaw Could Cause Widespread Trouble 372
BlueSharpieOfDoom writes "Whitedust has an interesting article posted about the new zlib buffer overflow. It affects countless software applications, even on Microsoft Windows. Some of the most affected application are those that are able to use the PNG graphic format, as zlib is wildely used in compression of PNG images. Zlib was also in the news in 2002 because of a flaw found in the way it handled memory allocation. The new hole could allow remote attackers to crash the vulnerable program or even the possiblity of executing arbitrary code."
Modularised code will always have this problem. (Score:5, Interesting)
Why are we still having buffer overflows? There's a compile option in Visual C++ that allows automatic buffer overflow protection. Does GCC have this switch? If so, why not? And why are people not using this? We have enough processing power on a typical PC to spend on these security such as this. Performance is not an excuse.
Looking further, this is an interesting example of the problems with monoculture. The BSD TCP/IP stack was copied for Windows and Mac OSX - this is great, it saves a tonne of time but you also means you inherit the exact same bugs as the BSD stack. This gives you an impression of how difficult it is to design secure operating system. If you borrow code such as this, you have to make sure it's secure. You can't really do that without line by line analysis which is unrealistic. In libraries the problem is especially accute. If you make a mistake in a well used library it could effect hundreds of pieces of software, as we've seen here.
We can't modularise security either, like we can modularise functionality, because you can take two secure components and put them together and get insecurity. Despite the grand claims people make about formal verification, even this isn't enough. The problem with formal verification is that the abstraction of the language you're using to obtain your proof may not adequately represent the way the compiler actually compiles the program. Besides, it's possible to engineer a compiler that deliberately miscompiles itself such that it compiles programs with security flaws in it.
What i'm trying to say is that despite what the zealots say, achieving security in software is impossible. The best we can do migitate the risk the best we can. The lesson to learn from security flaws such as this is that while code-reuse is good for maintainability and productivity, for security it's not great. As always, security is a trade-off and the trade-off here is whether we want to develop easy to maintain software quickly or whether we want to run the risk of these exploits being exploited. Personally, I fall in the code-reuse camp.
Simon.
Re:Modularised code will always have this problem. (Score:4, Interesting)
Is there? I haven't seen it. Even if there is (and I'm inclined to trust you), the reason that no one uses it is because it slows programs down so much. The pointer semantics of languages like C and C++ are fundamentally dangerous and the only way you can make them safe (checking every dereference individually) is painfully slow. I think a factor of three or four was the general consensus on /. last time this debate came up.
I guess it's about time for the Slashdot trolls to start calling for the end of C and C++. Strangely, I think I'm starting to agree with them, at least above the kernel level. Is speed really so critical in zlib?
Re:Modularised code will always have this problem. (Score:5, Interesting)
See here [developer.com]
On the broad issue on whether we should be using other languages, I think that saying "the programmer should carefully" is a bit misguided. Humans make mistakes and this is something that computers can do very well. Besides, if coding in such languages is slow, we can use a profiler to find the hot-spots and optimise the slow section using a lower level language.
For that reason, I don't really buy the "but it's too slow argument" - I think it's a good trade-off to use a language that doesn't allow buffer-overflows.
Simon.
Re:Modularised code will always have this problem. (Score:3, Informative)
Re:Modularised code will always have this problem. (Score:2)
Could some similar feature be supported by the operating system, or even the libc, by keeping track of every malloc, calloc, realloc, and whatever, reserving some memory space to store information about malloc'ed objects and their sizes?
Re:Modularised code will always have this problem. (Score:2)
The problem is the dereference beyond the range of the block. Either all dereferences have to go through the library (slow) or you need hardware support.
And even hardware support doesn't completely solve the problem. Nothing prevents you from hitting another block that was allocated, just not the one you're looking at.
Re:Modularised code will always have this problem. (Score:4, Informative)
There are a few reasons, though, why we don't use this system. One is that loading descriptors is slow because it was never optimized in the CPU with the equivalent of a TLB as for paging. The other is that using segmentation requires 48-bit pointers rather than 32-bit pointers, or it requires loading segmentation registers and doing a dance with those. I suppose using longer pointers was a problem back in the days when memory was scarce, but it's hardly a problem now (check out 64-bit). Intel *could have* made segment descriptor access checks and loading fast, but I guess there wasn't a demand for it once paging was available.
Re:Modularised code will always have this problem. (Score:5, Interesting)
The problem I have with the argument, "Sure the software checks in higher-level languages will slow things down significiantly, but computers are so much faster now," is simple. Ever notice how even as memory/video card frame-rates/hard-drive space increases exponentially it seems that the newest applications tend to still max them out to compete? Well the same thing applies to speed. It's tough to explain to your manager that you are going to purposefully use a language that cripples the efficiency of your newest application to anticiplate your own carelessness. (I'm not saying I'm any better than anyone else on this point. I've had my share of careless programming moments myself).
Does anyone know of any disadvantages to the NX bit that I don't know about? (Like significant slow-down worse than software checks or possible overflows that it would miss).
Better yet... (Score:3, Informative)
Re:Modularised code will always have this problem. (Score:4, Insightful)
We are talking about a low level LIBRARY here. Which means reentrant, placement independant code, efficiency, API accessible easily to any language and compiler.
I think all of this is still very difficult to do right in other languages than C. It is already very difficult to do in C++.
Anyway, your language without buffer overflows would not use pointer arithmetic, so would create a zlib a lot slower than the one we now, even if you optimise your high level language to the max.
When you see that what takes time are basic lines of your language, you are toast.
Re:Modularised code will always have this problem. (Score:2, Insightful)
In the first case most users will just open the file to check the contents, which is a feature, fast access means you'll use the files in another way. An 8 second access time slows you down, so you'll be less inclined to check the contents.
This goes for everything in computing. Previewing a filter change in your image program before
Re:Modularised code will always have this problem. (Score:3, Insightful)
Re:Modularised code will always have this problem. (Score:2)
The updated complier is included in the latest version of the Platform SDK or the free command line compiler that Microsoft is giving away. I haven't actually used it, but I would suspect that most people would only activate it while they were in the process of testing.
Re:Modularised code will always have this problem. (Score:5, Insightful)
For some reason your comment is moderated 'troll', probably because you had the filthy guts of uttering the Forbidden Word 'Visual C++'.
However, your question is prefectly valid. Automatic buffer overflow protection only covers the straightforward buffer overflow problems, i.e. array index overflows. In the case of more complex pointer arithmetic, where most of these problems occur, automatic protection is not possible (at least not without losing the option of pointer arithmetic).
Re:Modularised code will always have this problem. (Score:3, Funny)
Actually, 'forbidden term' would be more appropriate. My bad.
Re:Modularised code will always have this problem. (Score:5, Informative)
Automatic buffer overflow protection only covers the straightforward buffer overflow problems, i.e. array index overflows. In the case of more complex pointer arithmetic, where most of these problems occur, automatic protection is not possible (at least not without losing the option of pointer arithmetic).
Actually, automatic checking is very much possible, and has been for years. For example, Bounds checking gcc [ic.ac.uk] (that website is down right now, so try my page on the subject [annexia.org]). That was written in 1994, and there are newer systems available now which don't have such a serious performance penalty.
The real solution is to stop writing critical code in C. Other languages provide bounds checking, and are faster and safer than C: for example OCaml [cocan.org] which I prefer nowadays.
Rich.
Re:Modularised code will always have this problem. (Score:2)
Archive.org has a mirror:
http://web.archive.org/web/20040611220045/http://
Re:Modularised code will always have this problem. (Score:5, Insightful)
> in C.
Yeah. Right. It pisses me off that whenever security gets spoken of here, someone comes up with this pathetic magic fix.
Look, for commonly used libraries like zlib, you can't code it in anything but C. That is because only a C library can be called from every other language out there. Code it in, say, Python, and suddenly you lost all but Python programmers. Same goes for almost everything else. Yay for reuse of code!
Point in case - you write "for example OCaml which I prefer nowadays". Keyword 'nowadays'. What happens when you move on to the next big thing that comes along? Can you call libraries written in OCaml from that language? Extremely unlikely. But I bet it supports calling C libraries, because no serious language can avoid that.
Lots can be done to make C code safer. For example using safe versions of all non-safe functions, and integrating with a proper security model in the OS to drop non-needed permissions. But dropping the only language that can share code with everything else out there is just silly.
Re:Modularised code will always have this problem. (Score:4, Insightful)
This is wrong. What you meant to say is that only a library using the C calling convention can be called from every other language out there. Heck, I can write libraries in Visual Basic of all possible languages, and still have them compile against a C program (on Windows, and I'm sure it'll work on other platforms if someone ports vbc). If a language can call C functions, then it is likely (with a little effort) to have functions called by C - or any language that can call "C".
I haven't used Python or OCaml, but if either of those languages can produce C-style
What's more, you say that C can work with (at least as a library) every other language out there. So what's the problem with a small C-language interface that just calls the Python function and returns the result?
Re:Modularised code will always have this problem. (Score:3, Informative)
Python can't, at least without embedding the python interpreter in the dll.
What's more, you say that C can work with (at least as a library) every other language out there. So what's the problem with a small C-language interface that just calls the Python function and returns the result?
Any language supports calling C libraries from that language
Re:Modularised code will always have this problem. (Score:3, Insightful)
So get over it, "Da Fokka", and all you other insecure OSS fanboys, too.
Actually, I agree with the first part of your post, I use VS.NET 2005 and I love it.
Here is a pointer [wikipedia.org] that will help you understand the first part of my post.
Re:Modularised code will always have this problem. (Score:4, Funny)
If so why not? - and if not, why so?
Why why not but not if not? Why not not?
Re:Modularised code will always have this problem. (Score:4, Funny)
Re:Modularised code will always have this problem. (Score:3, Informative)
However, all such methods introduce a very noticable performance penalty.
Furthermore, there are documented ways of bypassing all such stack protection mechanisms.
Stop bitching. Audit your goddamn code already. Or would you rather all the bugs be found by the bad guys (this one was found by the Gentoo security team)?
Re:Modularised code will always have this problem. (Score:2)
What does this mean? I tried to lookup "publicization" in a few dictionaries, but it doesn't seem to be a word. A little checking on your part was all that was necessary to not fall into the using nonsense words trap
Re:Modularised code will always have this problem. (Score:2)
So maybe such a form doesn't officially exist. Check Google; I'm not the only one.
Re:Modularised code will always have this problem. (Score:2)
Oh please. When are we going to get past, "I know! Let's just write perfect software all the time!"
It's well past time to start using typesafe languages for most software - at least in theory. Unfortunately I don't see how this will come about in the OSS world in the forseeable future, because no such virtual runtime exists.
The OSS JVMs are closest I guess, but without an OSS CLASSPATH they don't really count. Besides, there's no mainstream suppo
Re:Modularised code will always have this problem. (Score:2)
Re:Modularised code will always have this problem. (Score:5, Informative)
Oh please. When are we going to get past, "I know! Let's just write perfect software all the time!"
There will always be some subset of people who refuse to accept the impossibility of absolute perfection. I believe their thinking goes like this:
(I never had to work for anyone who said the above, but my brother in law, a coder for a large trucking company, had to put up with a "quality consultant" whose entire theory was essentially the above, punctuated with shouts of "attention to detail, people!" in between such lectures. A similar consultant is documented in an email in "The Dilbert Principle". Sadly, it's probably not the same guy.)
Re:Modularised code will always have this problem. (Score:3, Funny)
Get a clue, you anonymous turd. DJ Bernstein isn't working under the whip of a corporate master demanding working apps in murderous short timeframes. Furthermore, the existence of one brilliant man who can manage to keep enormous amounts of state in his head and turn out perfect code is not prima facie evidence that all who cannot are somehow lacking.
Personally, my goa
Re:Modularised code will always have this problem. (Score:2)
While we're at it we should stop doing automobile crash tests too, and just design goddamn safe cars already.
Re:Modularised code will always have this problem. (Score:2)
Shit gets through initial testing; the recalls and lawsuits over defects in cars attest to that, and so do these frantic patchfests to defects in software. That's why there exist security teams to go through previous code and find the critical bugs that slipped through.
Re:Modularised code will always have this problem. (Score:3, Insightful)
Your argument assumes that buffer overflows are a natural and unavoidable aspect of C programming. I can show you plenty of examples of C modules without buffer overflows. Writing a complex system without buffer overflows is only a matter of using these modules together with a carefully constructed interface.
I also doubt your argument that achieving security in software is impossible. People have been doing it for years and years. Unfortuately we are seeing more and more security breaks because the per
Re:Modularised code will always have this problem. (Score:2, Interesting)
This is a problem of education. When I was at school you learned to program C and assembler. If you made a stupid programming error you would notice it real soon. Now they mostly teach languages like java which hides most of the defensive progra
Re:Modularised code will always have this problem. (Score:3, Informative)
The people who build dams, bridges, etc., don't simply tell the construction crew to be be careful. They know that mistakes will be made, so they create protocols to minimize the likelihood of mistakes, and to maximize the likelihood of finding the mistakes that are made. For example, an in-law who works in avionics tells me that in any cable run that carries multiple cables, the cables are required to have physically i
The answer is Defense in Depth (Score:4, Interesting)
I don't disagree that building secure applications is hard, but it's certainly not impossible. Modularized code just adds another layer of compilcation and potentially confusion. Most of this can be addressed by documenting the design and interface constraints, and ensuring that they're followed. At that point even most security vulnerabilities are primarily implementation defects. Defects will of course still occur, but the trick is to build systems that fail gracefully.
Developers must to account for defects and expect that every form of security protection will fail given enough time and effort. This is why the concept of "Defense in Depth" is so important. By layering protective measures you provide a level of security such that multiple layers have to fail before a compromise becomes truly serious. Combine that with logging and monitoring, and a successful attack while usually be identified before damage is done.
Take the above vulnerabiliy and assume it exists in an exploitable form in a web app running on Apache with a Postgres backend. If the server had been configured from a "Defense in Depth" perspective it would be running in a chroot jail as a low privilege account. Any database access required would be performed through a set of stored procedures or a middleware component that validates the user session and restricts data access. SELinux or GRSecurity would be used for fine grained user control on all running processes. All executables would also be compiled with stack and buffer protection.
In the above scenario, you see that this single exploit wouldn't get you much. However, most systems are deployed with one layer of security, and that's the problem.
Re:Modularised code will always have this problem. (Score:5, Interesting)
The problem I have with this statement is that any checks that Visual C++ may have are at best a fig leaf. Buffer Overflow protection is something that has dogged not just programers but hardware manufactures for decades now. If security is of such great consern why not make the assembler do buffer checks?, why not the operating system? why not the processor?, why not create a ram infrasturcture called SDDR in which the RAM itself does not allow anything to be accessed without a secure hash? the answer to all of these questions is that for every solution, event the stupid one at the bottom, the buffer overflow might take on a new form or the security measures themselves may backfire.
Ultimatly the parent is IMHO over reacting, we are always going to have buffer overflows. This is not necissarily a problem so long as people are willing to disclose the vulnerability and work hard to get it patched before an exploit is out in the wild. This is the main argument as to why Microsoft software is insecure because often known vulnerabilites go months without being patched. They are getting better but they are nowhere near the transparancy displayed here. They made a mistake in coding, they are attempting to fix it but until all the vulnerable aplications are patched we need to be on guard for signs of malicious behavior from programs relying on zlib. In other words this is just a part of life in the world of computing.
Re:Modularised code will always have this problem. (Score:2)
Not officially, but back when I used gentoo there was -fstack-protector and IIRC one other switch which implemented stack smash protection and bounds checking. Despite it being a lot slower in theory, I never noticed a difference in practice (except when my programs crashed it'd be "Pointer error detected, aborting" rather than "Segmentation fault")
Re:Modularised code will always have this problem. (Score:2)
Does formal specification and verification eliminate all bugs and security issues? No. Do
Re:Modularised code will always have this problem. (Score:2, Insightful)
I can't resist:
Apperently they *don't* do this for everything, or you've just shown that code inspection won't trigger everything at all. And so does Visual C++'s rumoured "magical buffer overflow detection". Quite frankly, it's crap. It'll only trigger on *big* hefty overruns, and almost never on an off-by-one. And even when it triggers, all it does it put up the mightily annoying and terribly useless "DAMAGE detected after NORMAL block. Press Cancel to continue, Retry to
The patch, and the E-Week article and quote (Score:5, Informative)
Re:The patch, and the E-Week article and quote (Score:3, Interesting)
Anyone got some suggestions?
Re:The patch, and the E-Week article and quote (Score:4, Informative)
For specific builds of individual programs, trivial. There are dozens of good, fast, and robust binary patching systems available - xdelta, bsdiff, and jojodiff are three F/OSS options. Of course, bandwidth is cheap enough these days that most people who use binaries can just download the new version in its entirety.
A general-purpose fix that could be applied to any application using a statically-linked zlib would be much harder, possibly even impossible. This is one of the major advantages of dynamic linking - that a security update to the library in question can automatically benefit any application that uses the library.
Re:The patch, and the E-Week article and quote (Score:2)
Thanks for the pointers - amazing,
Important: Use a safe browser (Score:5, Funny)
So next time someone recommends a browser. Stop and wonder about what technology the latest browser has implemented properly without regard to any security issues, and remember that it will be decades before IE implements the technology (if it ever does) so it will be safe for quite some time, by being a stable browser that rarely changes.
Mods: This is not an attempt at troll, but a parody of the typical "This is why you should switch to Firefox" posts whenever a vulnerability involving IE. It should be painfully obvious, but then again most of you are on crack.
For those with IE on XP,2003 (Score:2, Redundant)
http://www.hunger.hu/win.html [hunger.hu]
Warning: the link causes BSOD because of a flaw in the image rendering algorithm of some windows component when it tries to render a huge image, the waiting times out and the kernel decides its better just to panic.
The link causes no problems on linux, as it's implementation is not faulty.
I think there is a patch for this fault on windowsupdate, but i can't be certain as i'm not using windows.
So long with the zealotry of IE's safeness.
Not just IE (Score:3, Informative)
/Mikael
Re:Not just IE (Score:2, Funny)
My stupidity squared.
Re:For those with IE on XP,2003 (Score:3, Funny)
Re:For those with IE on XP,2003 (Score:2)
Re:For those with IE on XP,2003 (Score:2)
Re:For those with IE on XP,2003 (Score:2)
Re:For those with IE on XP,2003 (Score:2)
That was mainly the point of my GP (sorry if my sarcasm wasn't apparent enough).
It is fairly plausible to assume that there are some platform specific bugs or design flaws, where a specific browser is not at fault, like in the case of this zlib bug or the case of the demonstrated windows image bug, therefor we cannot say that firefox sucks or ie sucks, just that "hey look, there is a bug in zlib which is used by this and that" or "hey look, there is a bug in this windows component/design wh
Re:Important: Use a safe browser (Score:2)
Re:Important: Use a safe browser (Score:2)
Re:Mods on crack!? (Score:3, Funny)
Slander! I only mod people down when I'm off crack!
Re:Important: Use a safe browser (Score:2)
Re:Important: Use a safe browser (Score:2, Funny)
Re:Important: Use a safe browser (Score:2)
"Wow, that's some attempt at spin. Too bad it's completely wrong."
-1, Completely missed the joke. And also completely missed the disclaimer on the joke noting it as such. Wow.
Already patched (Score:4, Informative)
Re:Already patched (Score:2, Informative)
Gentoo announced the bug July 5th [gentoo.org] and had the patch a day later.
Re:Already patched (Score:2, Informative)
On OpenBSD
No... (Score:3, Interesting)
Now once upon a time, a lot of distributions (and open source projects out of the box even) would just static link in libz for some reason or another, but after some security issues in the past that caused massive headaches for package maintain
even on Microsoft Windows (Score:3, Funny)
NOT WINDOWS! I was just about to move to it from this Linux thing!
welcome to four days ago: [ GLSA 200507-05 ] (Score:2, Informative)
Glad I'm running Linux. (Score:4, Informative)
It's interesting to read about these as they occur, but it's a nice feeling that my operating system is so well taken care of. Too bad that all personal computers aren't set up for this kind of timely response. I wonder about those millions of library computers, home PCs, small business computers, and other institutional setups where no one even understands the concept of an update, let alone regularly runs the Windows "security" update program.
Another reason to use Linux!
Re:Glad I'm running Linux. (Score:2)
I am writing this from my debian desktop.
Re:Glad I'm running Linux. (Score:4, Insightful)
A case for packaging systems (Score:5, Insightful)
But when you have a flaw in a very popular library like this, you'll be happy to know that all 354 programs using this library on your system will be safe once the shared library is upgraded... Windows users must upgrade every software manually, and they often won't be able to know precisely what software may be affected...
Re:A case for packaging systems (Score:2)
What's more, Windows not having a package manager doesn't mean they're necessarily worse off. Think about it - if the zlib code was in Windows, they could just update the affected DLLs using Windows Update. If it isn't in Windows, then by definition it wouldn't have been packaged anyway.
If you link with zlib the right way, easy to fix (Score:5, Insightful)
The trouble comes with those software authors that wanted to be clever and to 'cut down on dependencies' and included a whole copy of zlib statically linked into their application. Now you have to replace the whole app to remove the zlib security hole. The dependency on zlib is still there, just better hidden, and in a way that makes upgrading a lot harder.
If Microsoft had any sense, a zlib.dll would be bundled with Windows and then Office (and many other apps) could use it. But they wouldn't want to do that, partly because it would involve admitting that they use such third-party libraries.
Der.. (Score:2)
A company of that size doesn't sneakily use 3rd party software. They pay $$$ for 3rd party software they include, and they would only use 3rd party software if it was patented by a 3rd party, or prohibitively expensive to develop themselves. I'm pretty sure that does not include z-lib.
Re:Der.. (Score:3, Insightful)
I see. That must be why they not only use zlib, but also remove the copyright strings.
(Search for "microsoft") [zlib.net]
Re:If you link with zlib the right way, easy to fi (Score:5, Interesting)
The flip side of the argument is that installing a broken zlib will break all application that are dynamically linked, but have no effect on those that are statically linked.
Remember too that an upgrade to a dynamically linked function means that proper testing must include all software that uses that function. A statically linked application can be tested as a standalone unit.
The resulting isolation of points of failure and lower MTTR is often seen as an advantage in production environments.
I remember this specific situation occurring in a production environment I worked in. A common library was updated, causing the failure of multiple critical applications. The ones not impacted? Statically linked.
Both sides of the discussion clearly have advantages and disadvantages; they have to be weighed to determine the proper risk/benefit.
Re:If you link with zlib the right way, easy to fi (Score:2)
Re:If you link with zlib the right way, easy to fi (Score:3, Interesting)
That's why some people like to use (say) debian stable in production environments: security fixes are backported to the well-tested version of the lib, making a breakage quite unlikely.
Re:If you link with zlib the right way, easy to fi (Score:3, Informative)
Re:If you link with zlib the right way, easy to fi (Score:2)
Open Source zlib (Score:2)
It affects countless software applications, even on Microsoft Windows.
I thought Microsoft was proprietary and didn't use open source like zlib? Snicker. I guess Microsoft is being assimilated.
Perspective of non-C Programmers (Score:4, Informative)
This situation is unnecessary; the problem is that C is not a type-safe language, like ML, CAML, Haskell, Common Lisp, Scheme, Java, etc.
You could write that code in SML/CAML/Common Lisp and likely get it to run as fast or faster than the original (particularly if you did some space/time tradeoffs ala partial evaluation). Integration with the applications in the form of a library would be the tough part.
Here's a provocative bit from Paul Graham (Lisp expert entrepreneur) on buffer overflows [paulgraham.com].
It's the runtime... (Score:2)
Not only do languages like Lisp need a fairly extensive runtime, they need dynamic memory allocation and garbage collection, and when you share garbage-collected objects between languages (potentially between multiple languages each with their own allocation models) you're asking for a whole new kind of
Re:Perspective of non-C Programmers (Score:5, Informative)
Re:Perspective of non-C Programmers (Score:4, Informative)
Please. This is a very boring misconception about types. It's not a type error. It's a pointer arithmetic error. Nothing a type system à la ML, Java, CL, whatever would have corrected.
However, mandatory bound checking on arrays, at runtime, in those languages would have caught the problem.
There exist type systems that can catch these kind of errors, but they are very cumbersome, and not very practical.
Re:Perspective of non-C Programmers (Score:2)
There exist type systems that can catch these kind of errors, but they are very cumbersome, and not very practical.
Obviously the right thing to do would have been to use Ada or SPARK which have runtime checks, and in the caes of SPARK extended static checking and formal verification. The real question is: How secure do you want to be? For a random desktop appliation such measures might be going a b
Re:Perspective of non-C Programmers (Score:2)
Please. This is a very boring misconception about types. It's not a type error. It's a pointer arithmetic error. Nothing a type system à la ML, Java, CL, whatever would have corrected.
No, you are wrong. The "pointer arithmetic error" that you mention is called (by experts) a "runtime type error".
A language like C that allows you to make type errors is "not type safe", which is why I wrote what I wrote.
Furthermore, not all programs that use ar
Re:Perspective of non-C Programmers (Score:5, Informative)
Why does this topic bring the, uh, technically challenged out of the woodwork?
I'm a Ph.D. computer science professor with 20 years of experience in design and implementation of programming languages, and the co-author of a C-like programming language [nickle.org] featuring static and dynamic typing and runtime operand checking. The parent poster is confused.
Static type checking involves automatically recognizing type-unsafe operations at compile time. In many programming languages, including C, if you write"s" - 1 the + operation is ill-defined, because the left-hand operand is of the wrong type: i.e., there is no string that is a legal operation to the - operator. The compiler can detect this at compile time and refuse to compile the program.
Dynamic type checking involves automatically recognizing type-unsafe operations at run time. In many programming languages, such as Python, if you write"s" - 1 inside a function definition, the compiler will not detect the problem, because the general problem of detecting this kind of error is unsolvable unless one restricts what programmers can write. Instead, the execution engine can detect the problem at runtime when the - is evaluated and refuse to continue executing the program.
Runtime operand checking involves automatically recognizing at runtime that an operation has an operand that, while of a type that might be legal for the operation being performed, is nonetheless illegal for that operation. In many languages, including Python, if you write 1 / 0 no error will be reported at compile time, because detecting such errors is in general impossible. Instead, the execution engine can detect the problem at runtime, and prevent execution from continuing.
(Of course, there also is such a thing as static operand checking, which bears the same relation to runtime operand checking that static type checking does to runtime type checking. This is a hot research topic right now.)
C's problem is that it (a) does not have a "safe" static type system, (b) does not have any dynamic type checking, and (c) has no operand checking. This combination of misfeatures is incredibly and obviously error-prone; offhand, I can think of no other popular language (not derived from C) that is broken in this fashion. Fixing (a) and/or (b) is not sufficient---(c) also needs to be fixed. Java, for example, has shown that this can be done in a C-like compiled language without noticeable loss of efficiency. (This was shown for PL/I more than 30 years ago, so it's no surprise.)
The parent post gives an example in which the index argument to an array dereference is of the correct type and has correct operands. If x[2] was evaluated, this would be an operand error, since the combination of arguments x and 2 is not a legal operand combination for the array dereference operator. With the statement as given in the parent post, I'm not sure what principle it was trying to illustrate. I think, though, that it doesn't much matter.
Re:Perspective of non-C Programmers (Score:3, Interesting)
We're pretty badly off-topic here, but what the hey...
C was first designed and implemented in the time period from 1969-1973 [bell-labs.com]. It is hardly a critique of its original designers and implementors that we have learned a lot about programming language design and implementation in the succeeding 30+ years, and that many of the constraints of the computing environment have been weakened or removed during that time. Indeed, some of the original designers [rdg.ac.uk] of C and UNIX spent a lot of time 10+ years ago developing
very complex code (Score:5, Interesting)
For comparison here [franz.com] is the deflate algorithm written in Common Lisp. It all fits neaty into a few pages. This is a far better language comparison example than the oft-cited hello world comparison.
Is i my imagination... (Score:3, Funny)
BSD Status (Score:5, Informative)
OpenBSD is affected, and was patched [openbsd.org] on the 6th of June
FreeBSD is affected, and was patched [freebsd.org] on the 6th of June
NetBSD base system is not affected, but a zlib from pkgsrc is, and was patched [netbsd.org] on the 8th of June
Re:BSD Status (Score:2, Informative)
Correct input validation is the key (Score:4, Insightful)
The fundamental problem is that all too often, different components of a system have are implemented with different input validation. For example a web browser component running an web application may accept all text input, whereas the backend database is only expecting a subset of text inputs.
Developers should establish what input the lowest level component and highest level components will require to get the job done and validate input into all components subject to these requirements. Where the lowest and highest level components have different requirements then the developer needs to define some method of encoding values that would otherwise be considered invalid, and ensure that all components enforce this encoding.
Correct interface design. (Score:3, Insightful)
Let's say, for example, that this overflow involves a pathological artificially created compressed stream. To test for it, you may have to implement most of the algorithms in zl
So, what's wrong with modularization? (Score:3, Insightful)
Re:So, what's wrong with modularization? (Score:2, Insightful)
Yes.
Simply updating one shared library (libz.so or zlib.dll) will fix the problem for all of your installed applications. No?
No. Some applications ship their own zlib and/or statically link to it, circumventing the benefits of modularity.
Zlib loaded with Spyware (Score:3, Funny)
Here is a sample of the Scan log.
Yawn (Score:4, Insightful)
Zlib itself contains 8000 lines of code. Not very big, is it? It's been around for years and is widely used, so in theory a lot of people have been able to look at it. And yet, after all these years, they are still finding buffer overflows in these 8000 lines of code.
Zlib was not written by monkeys. It was written by very smart, experienced coders. And yet somehow they are not able to write 8000 lines of code without multiple serious buffer overflows.
As long as code like this is written in C we're going to have these problems.
Saying, "there's a critical buffer overflow in a library written in C" is as newsworthy as saying "when I bang my head against the wall I get a headache."
Re:A skilled worker chooses his tools carefully (Score:2)
I'd far rather have an application that today is a little slower, but secure instead of fast but unsecure.
Zlib compression and decompression probably takes up a sizeable proportion of all CPU power in the world. Make it take twice as much processing power, and hell, you'd be impacting the environment because of the extra wattage used around the globe :P.
Seriously, though: its entire purpose is to be quick and transparent. If you double the amount of time it takes to compress everything, suddenly zlib be
Re:despite being OSS... (Score:4, Informative)
In fact, this flaw was found by a security audit of an open source project, not by any of the closed source projects (like Microsoft Office) that make use of it.
Re:I love when this happens (Score:3, Informative)
Please, learn how a Linux/BSD system work, how linked/static binaries work before start critiquing other distributions with non-sense.