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."
Any bets on how long before Microsoft issues a press release noting that this is yet another risk of using evil open source and open standards?
I do not deploy Linux. Ever.
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.
Here's what I want to know: the zlib maintainers know that their code is heavily used in open source product, and they can easily use ldd on a typical Linux or *BSD install to find out exactly which programs use zlib. So they know who to contact about vulnerabilities. However, if Microsoft just takes open source code and incorporates it into their products, how will the zlib folks know to contact them prior to public disclosure? It surely can't be the responsibility of the zlib team to grep through every single closed-source binary out there in order to make sure that it didn't use zlib.
It seems like if there isn't a mailing list for every single library's security issues, then closed source vendors will become second-class citizens when it comes to getting forewarning about a big security announcement like this. This seems like what has happened to Microsoft in this case; otherwise they would have had a raft of fixes available when the original story was released, right?
The other alternative is the vendor early warning list idea that Microsoft has been pushing, but the problem with that is: the more people on the list (and you'd have to have hundreds of vendors in the case of a base library like zlib, I'd think), the more likely that one of them will leak the story to the black hats, so that the delay while vendors prepare patches becomes a liability for the unpatched public. That doesn't seem like a good scenario to me either.
Your right to not believe: Americans United for Separation of Church and
is if when they released the patch for the security flaw they made the patch GPL... just imagine Microsoft having to recode all that stuff for themselves :)
' Ore stabit fortis a fine placet ore stat '
- found on a park bench
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.
Because we found out for Linux/Unix several days ago and got our systems fixed within 24 hours. Microsoft is still trying to figure out what the hell is going on.
*bash MS* bash bash bash....it's popular right?
It's popular, easy, and well-deserved in this case. So much for M$ paying attention to security. Someone in M$ should have known they used zlib code, exactly where it was, and gotten patches out in a reasonable timeframe. They didn't. Bash bash bash.
How am I supposed to fit a pithy, relevant quote into 120 characters?
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
...since DOS doesn't have a command called "pg".
Simpli - Your source for San Jose dedicated servers and colocation!
Its stupid to bring up the GPL or other open source licenses or argue about whether Microsoft is stealing code. I'm glad they use zlib. I'm glad they used portions of the BSD tcp/ip stack. I'm glad they decided to support (to the best of their ability) standards like C and HTML. I'm glad I don't have to depend on Microsoft anymore. But if they hadn't used open source programs I'd have never been exposed to other options except for the likes of Novell and Sun.
The real issue is that there is now a direct comparison on a shared bug (for which no exploit exists yet, let's not forget -- it's still theoretical) in both the free and proprietary systems.
You can see the cooperation and disclosure *and* resolution on the open source side. Did Microsoft even admit to the vulnerability which they surely (one hopes) knew existed in their own systems? No. That's not the issue either.
The great benefit that comes to open source from this is that now you can observe the different security and development models in action from a purely objective point of view.
Fortunately, for Microsoft and their customers at least, this is not so serious a flaw that it will likely be exploited before they can get fixes out -- if they really want to. Even more fortunately for Microsoft, there are already enough vulnerabilities with easy and existing exploits, that the zlib vulnerabilities will probably be a non-issue. Hackers will tend to follow the path of least resistance.
It is NOT a buffer overflow. Every is happy that your karma whoring because you know what a 'buffer overflow' is but your also helping spread this FUD.
The problem in zlib is a double free. It is only, and I repeat, only theoritically possible to exploit this in the same way that it is theoritically possible to exploit any undefined behavior.
Please don't counter with a traceroute exploit being an example of a double free because it wasn't. That was an example of free a garbage random data. There is quite a difference.
At any rate, please think before you post. I cannot believe everyone is making such a fuss over this. It's funny because XP's whole TCP/IP had a remote root hole in it and less noise was made here then is being made now over something that is only theoritically possible to exploit and also not yet proven to be reproducable.
Right now, this 'security issue' is entirely theoritical.
int func(int a);
func((b += 3, b));