Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Security

Security Bug Doesn't Discriminate 28

Posted by timothy from the let's-see-where-it's-fixed-first dept.
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."
This discussion has been archived. No new comments can be posted.

Security Bug Doesn't Discriminate More

Security Bug Doesn't Discriminate

Comments Filter:
  • We can expect the fixes for all the open source systems to come way before Microsoft's "investigation" is complete.

  • Description of security flaw from the article. (Score:1, Informative)

    by Anonymous Coward
    (Anonymous, so as not to be a karma whore)

    Researchers have identified a security flaw in a code library included in numerous popular applications that could enable an attacker to execute code on remote servers.

    The problem affects the External Data Representation (XDR) libraries derived from Sun Microsystems Inc.'s SunRPC remote procedure call technology. XDR libraries are used to translate data between systems, regardless of their architecture.
  • What was the original liscence for Sun's XDR library ? (genuine question)

  • calloc() vuln (Score:3, Informative)

    by m0rph3us0 ( 549631 ) on Tuesday August 06, 2002 @07:34PM (#4022449)
    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 [securityfocus.com]
  • From http://www.info.apple.com/usen/security/security_u pdates.html:

    Security Update 2002-08-02

    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.
  • 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-
    • Ummm... Everything with a BSD license?

    • FYI, MS's TCP stack isn't BSD-derived. Where do they use zlib, btw?
      • http://news.com.com/2100-1001-860328.html [com.com]
        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.
      • 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

        • The TCP stack that shipped with NT 3.51 and all later versions was written from scratch by Microsoft engineers. I know this because I co-wrote the Windows NT Winsock implementation and I worked very closely with the TCP guys. Can I prove this? No, but just because you read something in a WSJ article doesn't prove anything, either.
          • 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
        • 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 [kuro5hin.org] 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 [freebsd.org] 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.

    • Well, that's the way it is with the BSD license as well as several others: you might be allowing someone you dislike to use the code. If you license your code this way, it is best to be willing to be okay with it.
  • BUFFER OVERFLOW FOUND IN RPC!

Slashdot Top Deals

When you are working hard, get up and retch every so often.

Close