Slashdot Mirror


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."

28 comments

  1. There is a difference ..... by reaper20 · · Score: 1, Troll

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

    1. Re:There is a difference ..... by ceejayoz · · Score: 2, Insightful

      It'll be interesting to see if that happens.

    2. Re:There is a difference ..... by Van+Halen · · Score: 3, Informative
      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.

    3. Re:There is a difference ..... by Anonymous Coward · · Score: 0

      Ehh, forgot to add FreeBSD to the list of those already with patches. Oh well. And by the way, feel free to moderate this and the parent as Redundant, Flamebait, Troll, whatever you like!

    4. Re:There is a difference ..... by Anonymous Coward · · Score: 0

      and also OpenBSD with the new patches instead of the original ones.

    5. Re:There is a difference ..... by Anonymous Coward · · Score: 0

      OpenBSD has released a fix too (long time ago.)

  2. Description of security flaw from the article. by Anonymous Coward · · Score: 1, Informative

    (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.

  3. wt? by Anonymous Coward · · Score: 0

    "Despite all the fuss about Microsoft's booth at LinuxWorld next week...

    Excuse me, but what the fuck does that have to do with anything??

    1. Re:wt? by Anonymous Coward · · Score: 1, Interesting

      No kidding. Maybe the submitter thought that just having one link wasn't l33t enough. So he/she picked one obviously at random (since it has absolutely nothing to do with anything) and used it as a segue to the story. If I could figure out what the opposite of ingenious is, I'd use it here.

  4. Liscence ? by Brian_at_Work · · Score: 1

    What was the original liscence for Sun's XDR library ? (genuine question)

    1. Re:Liscence ? by norwoodites · · Score: 2

      BSD like, I think and still is.

    2. Re:Liscence ? by Anonymous Coward · · Score: 0

      I don't know about a liscence, but they may have a license. If you are that fucking stupid, maybe you should keep your comments to yourself.

  5. calloc() vuln by m0rph3us0 · · Score: 3, Informative

    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

    1. Re:calloc() vuln by brlewis · · Score: 2

      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.

  6. Mac OS X (client) isn't vulnerable by default by nebbian · · Score: 2, Informative
    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.
  7. Ah! Another "Derived" Work by Microsoft by Bob_Robertson · · Score: 2

    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-

    --
    The Ludwig von Mises Institute. The reasoning individuals economics
    1. Re:Ah! Another "Derived" Work by Microsoft by gmhowell · · Score: 1

      Ummm... Everything with a BSD license?

      --
      Jesus was all right but his disciples were thick and ordinary. -John Lennon
    2. Re:Ah! Another "Derived" Work by Microsoft by Dahan · · Score: 3, Informative

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

    3. Re:Ah! Another "Derived" Work by Microsoft by Evro · · Score: 2, Informative
      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.
      --
      rooooar
    4. Re:Ah! Another "Derived" Work by Microsoft by pthisis · · Score: 2

      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

      --
      rage, rage against the dying of the light
    5. Re:Ah! Another "Derived" Work by Microsoft by Kalzus · · Score: 1

      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.

      --
      "The Devil does not know a lot because He's the Devil, He knows a lot because he's old." -- unknown
    6. Re:Ah! Another "Derived" Work by Microsoft by km00re · · Score: 1

      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.

      --


      KM
    7. Re:Ah! Another "Derived" Work by Microsoft by pthisis · · Score: 2

      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

      --
      rage, rage against the dying of the light
    8. Re:Ah! Another "Derived" Work by Microsoft by Dahan · · Score: 2
      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.

  8. NEWS FLASH! by benjamindees · · Score: 1

    BUFFER OVERFLOW FOUND IN RPC!

    --
    "I assumed blithely that there were no elves out there in the darkness"
  9. Quite possibly. by Anonymous Coward · · Score: 0

    And it is totally within their rights.

  10. RPC Blooper by bmetzler · · Score: 0
    Since this is an RPC vulnerability, I thought I'd point out this RPC blooper I ran across recently.

    The phrase, "lost in the translation," is made to fit the global marketplace. In today's multicultural IT workplace, water cooler conversations may take place simultaneously in several different languages. IT professionals and their software, however, need to speak a common tongue. The subject of this "true IT blooper" learned that lesson the hard way.

    Every story in our bloopers series comes to us directly from a SearchWindowsManageability user. For obvious reasons, some contributors -- including this tale's author -- choose to remain anonymous. So, we'll call him Kim Chung.

    When Chung was a rookie security engineer, he was asked to handle his company's annual security audit. Anxious to make a positive impression on co-workers in his new department, Chung offered to stay late and run a few seemingly simple and routine system checks.

    One of Chung's chores was setting up a new security policy on 14 different Windows servers. As Chung set about changing this configuration, he was prompted by the system regarding its Remote Procedure Call service, "I didn't know much about RPC," He admits now. "All that I knew was there are tons of vulnerabilities concerning RPC services."

    After careful consideration of how to handle these settings, Chung said he came to this conclusion: "RPC? You evil!" So, he stopped all RPC-related services until two the next morning.

    As he continued to check additional RPC settings, Chung's system asked him to select a startup type. Well, he'd shut down RPC-related services. Also, he didn't have a high opinion of RPC. So, he chose 'never in use.'

    Looking back, Chung realizes that he didn't know what the heck "never in use" meant. Before taking the job in question, he'd only used Windows in Korean, and never the English edition. Even so, he thought he understood the command in the English version and carried on. He'd stayed late to do this job, by golly. He wasn't going to let that evil RPC stop him!

    Unaware that he had fouled up the configuration, Chung then restarted all of the systems. Around 2 a.m., he turned out the lights, locked the server room door for the night, and headed for home. "I was so sleepy!" he recalled.

    Before reviewing the rest of the evidence against Chung, a few words in his defense. Numerous studies show that sleep loss impairs the ability to perform tasks involving logical reasoning. () So, it's logical that Chung left without making sure that the restarted systems were operating properly.

    Sleep deprivation also affects memory. So, Chung didn't remember failing to check the systems. Indeed, he returned to work early the next morning with a spring in his step. His co-workers would thank him, he thought, for staying late so that they could go home. His boss would pat him on the back for getting up to speed on the predominately English network so quickly.

    What awaited him was complete disaster.

    "I had re-installed all the systems," Chung said. Selecting the 'never in use' option for the server's RPC services had caused the carefully constructed new configurations to be overwritten to their default settings upon his reboot.

    Was he embarrassed? Red in the face? Perhaps a little concerned about keeping his job? "It seemed that the earth was rocking and thunder was roaring to me," he said. That could be construed as a deep concern for one's job, don't you think?

    With the earth rocking beneath him and thunder roaring in his hears, our hero knocked on his administrator's door and turned the knob. Luckily, his boss chalked Chung's blooper up to lack of experience. So, Chung got off with little more than an `A' for effort and a stern warning: Watch your language!

    -Brent

  11. RPC 3.9 (late 1980s) by brlewis · · Score: 2

    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.