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.
Comment removed based on user account deletion
"The zlib library has been a fundamental open-source software component for almost a decade and can be found in almost every Linux and Unix system. That means the so-called "double free" flaw in the library may leave a hefty portion of Linux and Unix systems open to attack. Because it adopted some of the code, Microsoft apparently has made itself vulnerable to the flaw as well. "
Disclaimer: I am not a security weenie, so I don't know this for fact......*deep breath*....
If this is true, why is it only news for MS? It appears that Linux and Unix is also vulnerable. So why only set up the article as MS related?
*bash MS* bash bash bash....it's popular right?
Sent from your iPad.
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.
And Windriver or whoever controlled BSDI at the time made some serious cash in that deal. They got paid to make the tcp/ip stack work well in 2000/XP and they've done a good job of it.
I just wonder if Microsoft was able to taint some of the BSD coders by allowing them to view their code. I'm sure integrating something like a TCP/IP stack required access to some 2000/XP src code. Anyone know?
Can I get an eye poke?
Dog House Forum
http://www.gzip.org/zlib/apps.html
At least nine of Microsoft's major applications--including Microsoft Office, Internet Explorer, DirectX, Messenger and Front Page--appear to incorporate borrowed code from the compression library and could be vulnerable to a similar attack.
"Borrowed"? Whats the license for zlib?
----- Whats wrong with this picture? http://www.revoh.org:1234/whatswrong
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!
- AIX is dying.
- AmigaOS is dying.
- BSD is dying.
- BeOS is dying.
- CPM is dying.
- DOS is dying.
- FreeBSD is dying.
- GNU Hurd is dying.
- HP-UX is dying.
- IRIX is dying.
- Inferno is dying.
- Linux is dying.
- LynxOS is dying.
- MINIX is dying.
- MacOS is dying.
- Mach is dying.
- MicroC/OS is dying.
- NachOS is dying.
- NeXT is dying.
- Nemesis is dying.
- NetBSD is dying.
- NetWare is dying.
- OS-400 is dying.
- OS-9 is dying.
- OS/2 is dying.
- Oberon is dying.
- OpenBSD is dying.
- Palm OS is dying.
- Plan 9 is dying.
- pSOS is dying.
- QNX is dying.
- RTEMS is dying.
- SCO is dying.
- Solaris is dying.
- SunOS is dying.
- TRON is dying.
- ThreadX is dying.
- TinyOS is dying.
- Unix is dying.
- VMS is dying.
- VxWorks is dying.
- Windows 2000 is dying.
- Windows 3.11 is dying.
- Windows 95 is dying.
- Windows 98 is dying.
- Windows CE is dying.
- Windows ME is dying.
- Windows NT is dying.
- Windows XP is dying.
The Free On-Line Dictionary of Computing defines an operating system as: "The low-level software which handles the interface to peripheral hardware, schedules tasks, allocates storage, and presents a default interface to the user when no application program is running. The OS may be split into a kernel which is always present and various system programs which use facilities provided by the kernel to perform higher-level house-keeping tasks, often acting as servers in a client-server relationship. Some would include a graphical user interface and window system as part of the OS, others would not.The operating system loader, BIOS, or other firmware required at boot time or when installing the operating system would generally not be considered part of the operating system, though this distinction is unclear in the case of a rommable operating system such as RISC OS. The facilities an operating system provides and its general design philosophy exert an extremely strong influence on programming style and on the technical cultures that grow up around the machines on which it runs.
The comp.os.research FAQ makes the following distinction between micro- and macrokernels:
"A recurrent topic of discussion in this newsgroup has been the comparison between microkernel (for example Mach and QNX) and `macrokernel' (traditional Unix) operating systems. The basic notion of a microkernel consists of devolving as much functionality as possible into processes rather than the kernel itself; different systems take different approaches to implementing this.
For example, some systems (such as Mach) leave device drivers in the kernel, and place higher-level services (such as file systems) outside; others (such as QNX) move device drivers outside of the kernel.
However, anecdotal evidence [93-03-03-07-56.52] suggests that the distinction between microkernel and monolithic architectures is becoming more blurred as time goes on, as the two advance. For example, most modern monolithic kernels now implement multiple threads of execution and fine-grained parallelism. Architecturally, this approach begins to appear similar to a microkernel with several kernel-space processes working from shared memory.
As an aside, people often complain that the Mach system can't be a `real' microkernel, because it is so large (at least, this is the argument most frequently cited). However, I have been told that automatically-generated code stubs contribute very significantly to the size of the kernel, and that some size reduction would be likely if MIG (the stub generator) produced better code. [Can someone from CMU comment on this?] As mentioned above, the leaving of device drivers in the kernel also contributes to Mach's size.
Debating microkernels versus monolithic kernels on the basis of kernel size misses the central, architectural point. In the same way as the point of a RISC processor is not to minimise the instruction count, but rather to make a different tradeoff between what is implemented in the processor instruction set and what is implemented in other ways, the microkernel architectural issue is to determine which services are implemented in the microkernel, and which services are implemented external to that microkernel. By making appropriate choices here, the goal is to enhance various OS attributes in a manner that might not be addressable with a monolithic kernel OS. System attributes such as performance, flexibility, realtime, etc. are all variables which are taken into account.
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.
Well you seem to be implying that NT4 does not put the graphics code in the kernal, this is incorrect. This was one of the biggest "improvements" from nt 3.51 -> nt 4.0 is that the graphics subsystem got moved into the kernal for a speed increase. It is also (when coupled with crappy drivers) the second leading cause of nt instability after IIS =)
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
Why wait for a bug? Scan for "signatures". That's how the use of BSD's TCP/IP stack was determined (that, and the "Regent" copyright).
-- @rjamestaylor on Ello
Recent versions of Windows use a rewritten TCP/IP stack, so even if they did use the BSD stack for Win95/NT4/etc (which they almost definitely did, based on its behaviour), they aren't using it any more.
My machine has a bunch of stuff on it so a virgin
Win2K system MIGHT have different results but I
handchecked that the file's date matched the
install date on the machine. So CAVEAT EMPTOR...
a slightly fancier grep and some patience
find . -type f | while read f
do
strings "$f" | grep -i "Copyright " | grep -v Microsoft
test $? -eq 0 && echo $f
done
showed up Thomas Lane's open source JPEG work in multiple places, Mark H. Colburn's work in system32/pax.exe, Mark Adler's PNG work in at least system32/pngfilt.dll and a few more interesting cases.
system32/offfilt.dll has Mark Adler's inflate in it.
c:\Program Files\Common Files\Microsoft Shared\VGX appears to have zlib based upon this:
$ strings Program\ Files/Common\ Files/Microsoft\ Shared/VGX/vgx.dll | grep -i Copy
4,f deflate 1.1.3 Copyright 1995-1998 Jean-loup Gailly
f,f inflate 1.1.3 Copyright 1995-1998 Mark Adler
And Adobe Acrobat PDFWriter also uses zlib per system32/spool/drivers/w32x86/2/pdfdd.dll.
This is far from exhaustive of 100% scientfic but a good starting point.
--joel
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.
The security vulnerability is due to zlib trying to free the same section of memory twice. The glibc memory allocation routines aren't very smart, and will cause heap corruption if you try to do this. This heap corruption can be exploited.
The Microsoft runtime libraries have smarter memory allocation and deallocation - attempting to free the same area of memory twice does not result in heap corruption. Consequently the zlib bug isn't a security vulnerability in Windows.
Nope.
Microsoft doesn't oppose Open Source in general. They oppose certain licenses which happen to allow source code to be distributed, but which push a political ideology to REQUIRE all source code to be distributed.
Specifically, they oppose the GNU license, as do many, many smart people in the software industry.
People in history who think they know it all, who say 'our methods are the way forward, you may as well surrender to the truth' have often been frightening people. Lenin fit into the camp, as did Hitler.
It's never that simple.
The problem is that glibc doesn't handle the zlib bug properly, and the bug produces a buffer overflow.
So it's a bug in only Linux (which uses glibc) and all the hand waving here is an attempt to muddy the truth up.
The people who know their shit can figure it out in a few minutes. Then those in the know who are Linux advocates can wipe the egg off their face and get on with life.
The people who don't know shit, of course, will continue to run around trying to pretend it's not a Linux-specific security problem. The egg will dry on their faces.
Reading up on the zlib licence, which is short and easy to understand, I find this clause:
The way I read this, if software uses zlib code, then the authors of their software must not claim to have written the code. Microsoft are not obliged to acknowledge the zlib authors anywhere, but if they make a copyright statement saying that the code was written by Microsoft, then surely they are claiming that they wrote the zlib code in their product, and are therefor breaking this clause?Does anyone know if Microsofts' copyright statements comply?
I am probably too late for this point to be discussed.