Security Bug Doesn't Discriminate

An anonymous reader writes: "Despite all the fuss about Microsoft's booth at LinuxWorld next week, a security bug doesn't seem to care about the difference between open- and closed-source systems. The bug, found in a code library included in several popular applications, affects Windows 2000, Solaris, Mac OS X, and Linux, reports eWeek's Dennis Fisher."

Comments

Re:There is a difference .....

[ceejayoz]

It'll be interesting to see if that happens.

Re:Liscence ?

[norwoodites]

BSD like, I think and still is.

Re:There is a difference .....

[Van Halen]

According to the CERT advisory, the following (among others) have already released patches:

Apple (Mac OS X)

Debian (partial fix)

Glibc

MIT Kerberos

NetBSD

The following have not:

HP

IBM

Microsoft

RedHat

SGI

Sun

It may be interesting to see how quickly members of the second group catch up.

calloc() vuln

[m0rph3us0]

I believe this XDR vulnerabilty stems from a more serious problem in most implimentations of calloc()
The problem is created when the size of the ADT * numElements > a machine word
I'm parphrasing from this advisory on bugtraq

Re:calloc() vuln

[brlewis]

I think you're misreading the advisory. The bug in xdr_array.c does not stem from the calloc() bug. It's just that the same mistake caused both bugs.

Mac OS X (client) isn't vulnerable by default

[nebbian]

From http://www.info.apple.com/usen/security/security_u pdates.html:

Security Update 2002-08-02

• This update addresses the following security vulnerabilities which affect current shipping versions of Mac OS X Server. These services are turned off by default in Mac OS X client, however if these services are enabled then the client becomes vulnerable. It is recommended that users of Mac OS X client also apply this update.
• OpenSSL: Fixes security vulnerabilities CAN-2002-0656, CAN-2002-0657, CAN-2002-0655, and CAN-2002-0659. Details are available via: http://www.cert.org/advisories/CA-2002-23.html
  
  
• mod_ssl: Fixes CAN-2002-0653, an off-by-one buffer overflow in mod_ssl Apache module. Details are available via: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN- 2002-0653
  
  
• Sun RPC: Fixes CAN-2002-039, a buffer overflow in the Sun RPC XDR decoder. Details are available via: http://bvlive01.iss.net/issEn/delivery/xforce/aler tdetail.jsp?oid=20823
  
  

So unless you're a hardcore geek who turns on SSL, and hasn't yet updated to the latest security updates, you should be fine with your version of OS X (client). OS X Server users would probably have updated already.

Ah! Another "Derived" Work by Microsoft

[Bob_Robertson]

The TCP stack, zlib, now this.
It makes me wonder just how much of other peoples code Microsoft utilizes, and then locks down with their "Thou Shalt Not Even THINK About Reading This Code" end user license agreement...
Bob-

Re:Ah! Another "Derived" Work by Microsoft

[Dahan]

FYI, MS's TCP stack isn't BSD-derived. Where do they use zlib, btw?

Re:Ah! Another "Derived" Work by Microsoft

[Evro]

http://news.com.com/2100-1001-860328.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.

Re:Ah! Another "Derived" Work by Microsoft

[pthisis]

FYI, MS's TCP stack isn't BSD-derived. Where do they use zlib, btw?

Do you have a reference for this? The Wall Street Journal ran an article a year or so back where they investigated and concluded that the stack in Windows 2000 and XP is BSD-derived. Sadly, it's no longer available online.

Circumstantial evidence: Windows has historically exhibited a lot of security flaws consistent with a port of the BSD Net/3 TCP/IP stack (which other independent TCP/IP implementations haven't shown).

Windows 2000 and later seem to have moved from Net/3 to an OpenBSD/FreeBSD-based stack. It's impossible to know for sure, but you can use fingerprinting techniques (a la queso) to see things like Windows' TCP window size being 0x402E, which just happens to be exactly the same arbitrary number that Open/FreeBSD were using for the 2-3 years leading up to the Win2K release. There's no good reason for Windows to pick this number independently. There are a host of other, similar signs that demonstrate either MS used the open/freebsd stack or they spent a lot of time trying to duplicate subtle implementation details of the open/freebsd stack that aren't part of implementing the RFCs.

Sumner

Re:Ah! Another "Derived" Work by Microsoft

[pthisis]

The TCP stack that shipped with NT 3.51 and all later versions

The TCP stack shipping with Win2k and XP is clearly not the same stack that shipped with NT 3.51 and 4.0 (it may share substantial amounts of code, but even simple fingerprinting shows that it behaves quite differently).

I know this because I co-wrote the Windows NT Winsock implementation and I worked very closely with the TCP guys.

Okay, reality check here.

1. The Windows Socket: Background paper on MSDN says:
Windows Sockets are based on the UNIX® sockets implementation in the Berkeley Software Distribution (BSD, release 4.3) from the University of California at Berkeley.

2. Although the user-mode API for NT 3.5 was implemented entirely by Microsoft, the kernel TCP/IP stack originally included a stack licensed from Spider Systems. And the Spider Systems code was based on the BSD Net/3 TCP code. While much of the Spider Systems code (for the TCP stack) was rewritten before the release of NT 3.5, some of it remained. Much more of it remained in the userspace utilities (e.g. ftp.exe) and you could see the BSD copyright notice if you ran "strings" on that binary.

Can I prove this? No, but just because you read something in a WSJ article doesn't prove anything, either.

Like I said, either the Win2k/XP stack uses the open/freeBSD stack or the programmers implementing the win2k/XP stack referred heavily to the BSD code (even for non-RFC issues) or Microsoft went to great lengths to make it appear that way or there were some amazing coincidences with a number of the implementation details. The WSJ article is one thing, but the fingerprints the Win2k/XP stack has are extremely similar to the *BSD stack in many ways.

There's nothing wrong with this, it's perfectly legal and there's no advertising clause on open/freebsd any more AFAIK.

Sumner

Re:Ah! Another "Derived" Work by Microsoft

[Dahan]

Do you have a reference for this? The Wall Street Journal ran an article a year or so back where they investigated and concluded that the stack in Windows 2000 and XP is BSD-derived. Sadly, it's no longer available online.

Well, some guy on Kuro5hin wrote a rebuttal of that WSJ claim... maybe the guy's just making stuff up, but he says he worked at MS for 10 years, and knows the history of MS's TCP stack.

For one thing, he says that Spider Systems' stack was replaced by one written from scratch in NT 3.5 (which I assume means that Spider's stack was only in NT 3.1).

Now, he does say, "I won't even swear on a stack of bibles that the "new" TCP/IP now shipping in NT/2000/XP and Windows 95/98/Me is completely free of the old code from Spider," but even so, I really doubt if any actual BSD source code made it into Windows' TCP stack. I do think MS used BSD source as a reference to get the details on how things should work, which may explain the similarities and corner-case bugs. However, I don't think it'd be practical to actually lift the source code--the BSD and Windows kernel APIs just differ too much (heck, it's often not worth sharing source code between Linux and BSD drivers, and they're both Unixy... I know both sides look at the others' drivers for reference though). And it's my feeling that even Spider's stack was just based on Net/3; I don't think it contained much, if any, actual Net/3 source. After all, they did make the thing as a STREAMS module (according to the Kuro5hin guy), something pretty foreign to BSD.

But in the end, no, I don't have absolute proof that Windows' TCP stack doesn't have any BSD code in it. However, there's no proof that it does either, and it's annoying when people keep making the claim as if there were. Especially from what I know and what I've heard, I think it's more likely that there isn't any BSD code in there.

RPC 3.9 (late 1980s)

[brlewis]

I don't know about "original", but I can go back as far as RPC 3.9. They didn't even have a copyright notice. The license was almost entirely a disclaimer.