Slashdot Mirror
Microsoft, zlib, and Security Flaws
nakhla writes: "News.com is reporting that Microsoft's use of code from the open-source zlib library has led to possible security problems. The flaws in zlib were reported recently, and apply to several key Microsoft technologies, such as DirectX, Front Page, Install Shield, Office, and Internet Explorer. The article also mentions how this is not Microsoft's first use of open-source code in its software, but does point out that since zlib is not GPL'd they are under no obligation to release the source code to any of their products."
Quite a few people can, at universities and other sites. They just need to sign NDAs, that's all. Also, given that they take several hundred interns per year, and they aren't all fanatical Gates fans, there's a fair bit of opportunity for internal leaks as well.
Only the dead have seen the end of war.
InstallShield is written and published by a company named InstallShield, and has been for many years. It is not a "Microsoft technology", but rather a technology that has support for creating software installation routines for Windows, amongst other OSes.
--
"Outlook not so good." That magic 8-ball knows everything! I'll ask about Exchange Server next.
Argh! Bad statistics alert!
"vulnerabilities found in Windows and all Linux flavors combined are almost the same"
So if I am running RedHat, Mandrake, SUSE, and Debian simultaneously, I have the same number of flaws as a single run of Win2k?
They should either use the average (among linux dists) or the max (ditto), vs Win. Or sum across all current Win flavors (ME, Win2k. maybe NT) to compare against all linux flavors (summed).
Argh!
A.
I don't see it as the zlib author's responsibility to notify everyone that uses their library.
I do feel that they should (but are not obligated to) send out a few public notices that will be spread around so that people who's programs use the library can update it and that's exactly what they did.
Also the big problem with this security issue isn't programs that dynamically link to libz.so. Those are easy to fix because all you have to do is upgrade your zlib and they're automagically fixed.
It's the programs that statically link the zlib library (meaning it gets copied right into the actual binary at compile time) that you have to worry about because an ldd won't show you that.
Also many people use their own modified version of zlib (XFree86, rpm, rsync, the linux kernel etc.) and so those are very hard to catch as well.
Florian Weimer wrote a perl script which will check for binaries on your system that are statically linked. You can read his post to Bugtraq here.
--
Garett
How is reading, even verbatim copying, of BSD-licensed code risky in legal terms. The license explicitly allows incorporation into any type of software (commercial, open, or free). Microsoft could put out their own version of one of the *BSDs, with the only difference from it's base BSD being having the Windows GUI grafted on top of it and no source included.
The relevant passage in the BSD license (from http://www.freebsd.org/copyright/license.html ):
There are licenses that are the BSD license, less the advertising clause (it is the advertising clause that prevents BSD from being a free license according to the FSF), such as the MIT license. These licenses are the freest of all the licenses (short of public domain).
...that Microsoft uses free software, I invite you to take a look at this.
In Windows 2000, open a command prompt window. Type "nslookup". This will drop you into interactive mode for nslookup, which has been ported from UNIX (most likely BSD.)
Now type "help". Check out this line at the bottom of the output:
view FILE - sort an 'ls' output file and view it with pg
Uh, yeah. Oops.
Simpli - Your source for San Jose dedicated servers and colocation!
The problem is a buffer overflow which is a lot more serious than a crash.
// set up a buffer that's 1024 bytes // read data into buffer
I apologize in advance if I'm being a little too trivial but I'm assuming that you are 100% non-technical just incase this post appeals to someone or some people who are.
When a program needs to temporarily store an ammount of data it uses what's called a buffer. This is just a segment of memory where it can store it's data.
A buffer overflow occurs when the buffer get's filled past it's allocated regions. So in other words let's say the programmer has set up a buffer that's 1024 bytes. An overflow is when the user fills that 1024 byte buffer with more than 1024 bytes.
What happens? Well ideally the extra data wouldn't get stored in memory at all but unfortunately computers don't work that way. Instead whatever is stored in memory AFTER the 1024 bytes gets overwritten.
So let's say the programmer had the following code in his buggy program.
buffer[1024]
read data, buffer
do something
What the hacker has to do is input 1024 of garbage and then overwrite the memory with some other computer instruction. Like the instructions necessary to execute a shell.
You see when the buffer is overflown the "do something" instruction will get overwritten with whatever data the hacker puts into the buffer. If the program is running as root then when the "do something" instruction is overwritten with the instructions to execute a shell the hacker will have himself root access!
But it's even more serious than that becuase let's say the program is a web server running as nobody. Before the hacker exploits the buffer overflow he has no access. But he knows about this overflow so he overflow's it by sending apache a very long request containing the instructions to execute a shell. He has just gained "nobody" access to the system and from there he can figure out how to get root access.
The solution is for the programmer to make sure that the user is only entering in 1024 bytes of data at the most. Unfortunately many programs weren't written to do this.
I hope this explains to people why these bugs are more serious than "my system will crash".
--
Garett
it's a double-free problem. the two are totally different.
read all about it : http://www.gzip.org/zlib/advisory-2002-03-11.txt
-c
I have discovered a truly remarkable proof which this margin is too small to contain.
I do feel that they should (but are not obligated to) send out a few public notices that will be spread around so that people who's programs use the library can update it and that's exactly what they did.
Unless I am missing my guess, I ran into this particular bug in zlib about a year ago and I e-mailed the people at the project address. They responded that they already knew about it and sent me the patch. So what exactly is it that happened recently? Did someone figure out a way to use the bug to crack a system and this set off all kinds of alarms? There should have been a zlib fix-up release a long time ago.