Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×

Apple Patches Wireless Drivers 143

Posted by CowboyNeal from the back-on-track dept.
Frank writes "Apple quietly released a pair of patches today to its wireless drivers. The patches (one for PowerPC, one for Intel) address distinct buffer overflow vulnerabilities found during an internal audit in response to the claim that fuzzing the drivers resulted in an exploitable failure."
This discussion has been archived. No new comments can be posted.

Apple Patches Wireless Drivers More

Apple Patches Wireless Drivers

Comments Filter:

  • Details (Score:5, Informative)

    by Lord Grey ( 463613 ) * on Thursday September 21, 2006 @08:28PM (#16158354)
    For those that like details, here is more specific information on the patch: About the security content of AirPort Update 2006-001 and Security Update 2006-005 [apple.com].

  • erhm (Score:5, Funny)

    by User 956 ( 568564 ) on Thursday September 21, 2006 @08:30PM (#16158363) Homepage
    Apple quietly released a pair of patches today to its wireless drivers.

    What, you expect them to loudly release a pair of patches? "Hey, everybody, our products have a flaw which allows them to be wirelessly rooted in under a minute! Better apply this patch!!!1!!one!"

    Somehow I don't think that would go over too well on Wall Street.

    • Re: (Score:1)

      by Mikachu ( 972457 )
      That's what microsoft does :P

    • Re:erhm (Score:5, Insightful)

      by bobalu ( 1921 ) on Thursday September 21, 2006 @08:36PM (#16158389)
      I think that's a bit harsh. And since I know both my neighbors and they're both developers who I'd trust with my network, and they're both over 200' away, I could give a flying rat's ass anyway.And if Wall Street gave f**** about network security Microsoft would be trading at $1/share.
      • And since I know both my neighbors and they're both developers who I'd trust with my network
        What?! Did somebody declare detent in the forever war between systems administrators and developers whilst I was not paying attention? Never trust a developer with your network! Trust developers with your source code. (Never trust an admin with your source code! (save possibly to back it up...)
    • IIRC, a few weeks ago they were adamant that there was no flaw. Seems even darling companies can make mistakes too.
      • It just sounds exactly the sort of thing politicians do, deny there is ever any problem, quietly legistlate, and then when it comes to an election they can say how wonderful they are at the problem they identified and fixed themselves.

        I wonder if Steve is planning on running ;)

        • Re: (Score:3, Funny)

          by Firehed ( 942385 )
          Well other than the national dress code of a black turtleneck and blue jeans and Lattes becoming the official drink of the country, it's not that bad of an idea.

      • Re:There's no flaw, but heres a patch anyway (Score:5, Informative)

        by Rosyna ( 80334 ) on Thursday September 21, 2006 @08:53PM (#16158449) Homepage
        The "flaw" that SecureWorks reported did not exist. Apple wasn't told [macworld.com] what the flaw was or really any details about it, and like a responsible company, audited all relevant code irregardless. They found three potential *crashers*. These may be impossible crashers, as in the requirements to get to that section of code means it is impossible for the data to be invalid, but they added an error check "just in case".

        The problem is now days everyone considers a crasher to be a security exploit, even if it can't be used to run any code.

        But none of these are what the SecureWorks guys "reportedly" found. Either way, they definitely and without a doubt lied on that video. The device they attached was not a wireless device seen by the system at all. The SecureWorks guys never even stated anything, other than the community didn't have the mental capacity to understand what the exploit was.

        They also said they would not release details until Apple fixed it. So I assume they'll now put up or shut up. It really all looks like a publicity stunt to sell their upcoming book [amazon.com].

        • Re:There's no flaw, but heres a patch anyway (Score:5, Informative)

          by martinbogo ( 468553 ) on Thursday September 21, 2006 @09:47PM (#16158608) Homepage Journal
          Actually .. there *IS* a flaw, as stated by Apple in the release, that does exactly what the SecureWorks people stated.

          From the security release:

          CVE-ID: CVE-2006-3507

          Available for: Mac OS X v10.3.9, Mac OS X Server v10.3.9, Mac OS X v10.4.7, Mac OS X Server v10.4.7

          Impact: Attackers on the wireless network may cause arbitrary code execution

          Description: Two separate stack buffer overflows exist in the AirPort wireless driver's handling of malformed frames. An attacker in local proximity may be able to trigger an overflow by injecting a maliciously-crafted frame into a wireless network. When the AirPort is on, this could lead to arbitrary code execution with system privileges. This issue affects Power Mac, PowerBook, iBook, iMac, Mac Pro, Xserve, and PowerPC-based Mac mini computers equipped with wireless. Intel-based Mac mini, MacBook, and MacBook Pro computers are not affected. There is no known exploit for this issue. This update addresses the issues by performing additional validation of wireless frames.

          • Re:There's no flaw, but heres a patch anyway (Score:5, Informative)

            by Drishmung ( 458368 ) on Thursday September 21, 2006 @10:04PM (#16158664)
            The SecureWorks people claimed to have compromised a MacBook. That is, an Intel based machine.

            But, as you quote:

            Intel-based Mac mini, MacBook, and MacBook Pro computers are not affected

            IOW, this is evidently not the same vulnerability claimed by SecureWorks.

            Stumulated by the brouhaha, Apple have performed a code audit. (I'd suspect they did a remarkably thorough code audit too :) They have found some problems with the PPC drivers, and they have released a patch for them. They don't appear to have found any issues with the Intel code though.

            • Re: (Score:2, Informative)

              by epee1221 ( 873140 )

              IOW, this is evidently not the same vulnerability claimed by SecureWorks. Stumulated by the brouhaha, Apple have performed a code audit. (I'd suspect they did a remarkably thorough code audit too :) They have found some problems with the PPC drivers, and they have released a patch for them. They don't appear to have found any issues with the Intel code though.

              Very true. I wonder why they didn't catch the code said to be responsible for Johnny Cache's exploit. Maybe that's because it's Atheros' driver co

              • Stop. You are misinformed. The second item in the announcement, CVE-2006-3509, is for the Atheros driver. The third is for Apple's API on the same computers. We don't know if an exploit exists, and we don't know where the flaw might be if it does exist. We don't even know if it's patched, because Apple has said SecureWorks was not working with them. So, rather than recklessly speculate with the incomplete information available to us, let's see what Maynor and Ellch have to say about their possible exploit:

                "

            • Re:There's no flaw, but heres a patch anyway (Score:5, Informative)

              by dragonman97 ( 185927 ) on Thursday September 21, 2006 @11:39PM (#16158967)

              AirPort

              CVE-ID: CVE-2006-3508

              Available for: Mac OS X v10.4.7, Mac OS X Server v10.4.7

              Impact: Attackers on the wireless network may cause system crashes, privilege elevation, or arbitrary code execution

              Description: A heap buffer overflow exists in the AirPort wireless driver's handling of scan cache updates. An attacker in local proximity may be able to trigger the overflow by injecting a maliciously-crafted frame into the wireless network. This could lead to a system crash, privilege elevation, or arbitrary code execution with system privileges. This issue affects Intel-based Mac mini, MacBook, and MacBook Pro computers equipped with wireless. Power Mac, PowerBook, iBook, iMac, Mac Pro, Xserve, and PowerPC-based Mac mini computers are not affected. This update addresses the issue by performing additional validation of wireless frames. There is no known exploit for this issue. This issue does not affect systems prior to Mac OS X v10.4.

              It sure looks like it affects Intel-based Apple laptops to me. I don't buy the spin - I think it's quite likely the SecureWorks guys are right...and if they're wrong, well then these computers are just more secure. That sounds like a /really bad thing/ to me.

            • IT DOES AFFECT MACINTELS, 'mung... (Score:1, Informative)

              by Anonymous Coward
              CVE-2006-3508 Available for: Mac OS X v10.4.7, Mac OS X Server v10.4.7
              Impact: Attackers on the wireless network may cause system crashes, privilege elevation, or arbitrary code execution
              Description: A heap buffer overflow exists in the AirPort wireless driver's handling of scan cache updates. An attacker in local proximity may be able to trigger the overflow by injecting a maliciously-crafted frame into the wireless network. This could lead to a system crash, privilege elevation, or arbitrary code exec

          • Re:There's no flaw, but heres a patch anyway (Score:5, Interesting)

            by powermacx ( 887715 ) on Thursday September 21, 2006 @10:43PM (#16158805)

            You highlighted the wrong part. Let me fix that for you:

            Impact: Attackers on the wireless network may cause arbitrary code execution Description: Two separate stack buffer overflows exist in the AirPort wireless driver's handling of malformed frames. An attacker in local proximity may be able to trigger an overflow by injecting a maliciously-crafted frame into a wireless network. When the AirPort is on, this could lead to arbitrary code execution with system privileges. This issue affects Power Mac, PowerBook, iBook, iMac, Mac Pro, Xserve, and PowerPC-based Mac mini computers equipped with wireless. Intel-based Mac mini, MacBook, and MacBook Pro computers are not affected. There is no known exploit for this issue. This update addresses the issues by performing additional validation of wireless frames.

            The same "no know exploit for this issue" line is on the other two CVEs. So, Apple is saying the the claim made by the SecureWorks guys to Krebs ("the same exploit works on the internal Airport card") is a BIG FAT LIE: they did not have an exploit or if they did, they lied when they said they had shared the details with Apple.

            • Re: (Score:2)

              by Sancho ( 17056 )
              So, Apple is saying the the claim made by the SecureWorks guys to Krebs ("the same exploit works on the internal Airport card") is a BIG FAT LIE: they did not have an exploit or if they did, they lied when they said they had shared the details with Apple.

              This is what Apple has been saying all along. This is not a change, not news, and certainly not any further proof that they are telling the truth (i.e. there's really no way to know whether or not Maynor /actually/ talked to them or not).
              • This is what Apple has been saying all along. This is not a change, not news, and certainly not any further proof that they are telling the truth (i.e. there's really no way to know whether or not Maynor /actually/ talked to them or not).
                Except now they are saying this on a technical document whereas previowsly it was "just" a PR guy so they could have claimed "miscomunication".

          • Re:There's no flaw, but heres a patch anyway (Score:5, Informative)

            by Anonymous Coward on Thursday September 21, 2006 @11:02PM (#16158872)
            There is no known exploit for this issue.


            This is like most "exploits." You find a crash situation, it's some overflow of somekind, you wouldn't seg fault other wise. Everyone freaks out, it might be possible to run arbitrary code, it might not be. OpenSSL had a fairly famous one about 3 years ago, the ASN.1 decoder had a crash when you put corrupt certificates in to it, at best it was a type of DoS situation and to this day nobody has ever run arbitrary code with it.


            This secureworks thing is the very worst kind of "security" out there. Thing is, just about all code of a certain size has flaws. This includes drivers. Potentially, a defect in a driver is really bad, it's trusted code that executes usually in ring-1 or ring-0. These most likely won't be the last security fixes Apple puts in to their wireless drivers, it's enough code and big enough that there will be more bugs that are found.


            Now I've written more and a couple wireless drivers myself and I happen to know that there is next to no way that the secureworks "exploit" works like they claim. I'd be a lot more willing to believe it if they explained that it was a microcode flaw they found or if the device was already associated with something. Some chips, like the Atheros, have a firmware that pretty much does everything and you write not a lot more than an ethernet driver on top of it and you can have wireless, you do another layer of stuff to control some of the tweakables (channel, b or g, etc.. but those are fairly static values you poke in to registers) their firmware will do WPA, WEP, all that crap. So their microcode engine isn't your normal microprocessor, crafting code for it, enough code to associate or send arbitrary packets is an impressive task. It's also rtos based, with no memory allocation, static buffers, and while it's possible that there are some overflows, I think it's pretty unlikely. It seems very believable that you could jam crappy frames in and cause it to hang or drop them in some way but overflow with enough code space to arbitrarily establish a connection to a remote machine? It's also a long way off from the OS. Crafting some frames that cause the OS to start doing that is almost more impressive, I think it's a lower hanging fruit in many ways but you have to trick the whole stack, there are checks along the way, does the OS think it's a raw socket? That never got constructed? It can't be going through the IP stack, data will get dropped at numerous places, not the least of which would be routing. If they crashed the microcode, color me stupid, but I don't see how that get's you to a userspace process or even close to it. There are a lot of things they could reveal about it if they have a real exploit that wouldn't completely reveal the hardware in question. But let's look at that too, how many 3rd party wireless parts are their for MacOSX? 2 or 3?

            • Re: (Score:2)

              by elrous0 ( 869638 ) *
              it might be possible to run arbitrary code, it might not be.

              That's not exactly a very comforting reassurance.

              -Eric

            • The Atheros chipsets uses software radios, no microcode. Same with Broadcom. So if you can get arbitrary code execution there, you're running within the kernel.

              However, many of the Prism chipsets (whoever owns them nowadays) used their own processor, an ARM, as did some Atmel chipsets.

        • Re: (Score:1, Insightful)

          by Anonymous Coward
          The problem is now days everyone considers a crasher to be a security exploit, even if it can't be used to run any code.

          The real problem these days is that crashers which nobody ever thought could be used to run code have been cleverly exploited.

          First it was just stack buffer overflows.

          Then some clever person figured out how to exploit seemingly-unexploitable heap overflows.

          Then it was double-frees and dangling pointers.

          The claimed wifi driver exploit is supposedly a fancy timing attack which hits a race co

      • Re: (Score:2, Informative)

        by gabebear ( 251933 )
        The flaw announced by SecureWorks was supposedly in a third-party wireless driver for MacOS, not Airport. The article says SecureWorks never gave any proof of a flaw in Apple's drivers, but that they audited them because of SecureWorks announcement and that these patches are the result.

        Apple is still adamant that SecureWorks didn't find any flaws.

        • Re:There's no flaw, but heres a patch anyway (Score:5, Informative)

          by catwh0re ( 540371 ) on Thursday September 21, 2006 @10:15PM (#16158716)
          "Apple is still adamant that SecureWorks didn't find any flaws."

          I believe just about everyone is adamant that SecureWorks didn't find any flaws.

          Since their initial statement which was launched on digg with a title that read something similar to: "Own a macbook in under 60 seconds". They have claimed the following:
          - Fault works on macbooks and most other wireless hardware, platform independent.
          - Apple had muscled them into not demonstrating it on apple hardware, instead 3rd party hardware.
          - They had informed Apple and other companies of the fault, gave the required details and instructions.
          - Will demonstrate the flaw on video as to protect the packets from being sniffed.

          Now since the demonstration of the video the following has come out of the woodwork
          - These updates do not patch intel based macs such as the macbook.. nor do they patch anything described by SecureWorks
          - Apple had never spoken with SecureWorks or it's employees about the "flaws" before the blackhat conference.
          - SecureWorks have not informed Apple or any other company of the flaws or gave required details to reproduce them.
          - The demonstration on video has been dubious and clearly shows 3rd party hardware being used, with there being no proof that this is a wireless flaw or just a hoax.
          - SecureWorks has gone mostly silent on the issue, and have changed their story several times, they have never released details to validate -any- of their claims.

          The whole thing has been a terrible farse with the perpetrators reeling into hiding after realising that this is something which the public would want proven and not just take their word for it.

          No one expects any platform to be 100% secure, but when you find a fault, particularly one as interesting as a remote wireless hack, you will instantly have a huge audience wanting it proven and demonstrated, they deserve being outcast like they have. Their methods are being publicy dealt with in the same way that a disgraced scientist would be.

          • Re: (Score:3, Informative)

            by catwh0re ( 540371 )
            Just to correct the above, of the new patches (3 of them) only some are for the intel macs and some are for the ppc macs. Different flaws exist on different hardware configurations, one requiring 3rd party devices also.

        • Re:There's no flaw, but heres a patch anyway (Score:4, Insightful)

          by Saint Fnordius ( 456567 ) on Friday September 22, 2006 @04:57AM (#16159611) Homepage Journal
          Rather, Apple is adamant in stating that SecureWorks never contacted them. This is important because SecureWorks tried to make it look like they told Apple, but Apple leaned on them to hush it up.

          I'm with John Gruber of Daring Fireball on this: my money is on Apple telling the truth. The risks of them getting spanked should it be a lie are too high, and the number of times security companies pull stunts to drum up business doesn't look good for SecureWorks.
      • Sorry, but you don't remember correctly. Apple stated that SecureWorks had not demonstrated any vulnerability in the AirPort drivers to them. As far as anyone knows, this is true. The SecureWorks people never owned a MacBook through exploiting AirPort drivers.

  • Additional background info (Score:4, Informative)

    by richg74 ( 650636 ) on Thursday September 21, 2006 @08:31PM (#16158366) Homepage
    Brian Krebs, at the Washington Post, has some additional background information and comments in his "SecurityFix" blog. [washingtonpost.com]

    • Re: (Score:3, Interesting)

      by Jeff DeMaagd ( 2015 )
      The problem with the whole story is that David Maynor was saying it was the Intel drivers that was at fault, which is an interesting problem because Apple's current notebooks use Aetheros wireless chips.

      • Re: (Score:3, Informative)

        by Sancho ( 17056 )
        The problem is that nobody gets the story right.

        Maynor and Cache said that similar flaws existed on many platforms. They said that Intel's drivers had the flaw, and that it was funny that Intel had released a new driver version a week before Black Hat. They also said that the flaw was exploitable on the MacBook using the third-party device and drivers. And they also said that the flaw was exploitable on the Airport with Apple's own drivers.

        Now I don't know who to believe in this--both parties have a stak

  • This does NOT make the SecureWorks story true! (Score:5, Informative)

    by macmaxbh ( 679230 ) * on Thursday September 21, 2006 @08:33PM (#16158378)
    I'll let MacWorld say it for me:
    From http://www.macworld.com/news/2006/09/21/wireless/i ndex.php [macworld.com]:
    Apple on Thursday released a Security and AirPort update for Mac OS X that fixes vulnerabilities found in the company's wireless drivers. Apple said the issues found were the result of an internal audit of the software drivers and that no known exploits exist for the issues addressed in this update.
    ...
    Apple has maintained that SecureWorks has provided no proof that Mac drivers are vulnerable in any way.
    "They did not supply us with any information to allow us to identify a specific problem, so we initiated an internal audit," Apple spokesman, Anuj Nayar, told Macworld. "Today's update preemptively strengthens our drivers against potential vulnerabilities, and while it addresses issues found internally by Apple, we are open to hearing from security researchers on how to improve security on the Mac."

    • Re: (Score:2)

      by Ilgaz ( 86384 )
      I like Macworld, trust them on product reviews but their apologising (?) for Apple is a fanboy response not suitable for a independent, professional publication.

      Also the Mac community who keeps attacking the messenger started to bug me seriously as a Mac user who is concerned about own security.

      I own a Quad G5, do my entire work on Macs, there is no PC around and while posting to Apple stories, I unclick "No Karma Bonus" since I know what will happen. Mac zealots are the biggest security risk to OS X/Macint
  • I get panics on my MBP, in the same few memory locations, when loading the wifi heavily. For instance, using scp or nfs will trigger a panic within a few minutes. This only happens when the wifi is on; ethernet works fine. I've been waiting to take it in for repair until such a time as Apple A) acknowledges all the other problems (heat, whine) I want fixed on this POS, and B) I can stand to do without my beloved POS for a week or so.
    • Apple is currently investigating that issue. Don't take it into the store just yet, they can't offer a solution. Once apple engineering figures it out then we'll see what the fix is.

      As to the heat, yes it's a hot machine, nothing can be done about that. They chose to make the machine quiet (the fan hardly ever spins on) but hot.

      As to the wine, if it's excessive they can have things replaced; but there will always be a small whine. It's mainly because of the higher voltages (the macbook pro uses an 80 watt p
  • Whadya know? There IS an AirPort update in my Software Update thingy.

    "Apple never told me that...I had to hear it from Slashdot."

  • Dell also released Wireless Patch (Score:3, Interesting)

    by Anonymous Coward on Thursday September 21, 2006 @09:24PM (#16158538)
    I have a Core 2 Duo laptop with the Intel Wireless chipset. Yesterday I pulled down a "Critical" patch and installed it. It think both Apple and Dell are using the same Intel chipsets, so this is apparently an Intel fix.

  • A near miss... (Score:2, Insightful)

    by Anonymous Coward
    Luckily not enough people actually use Macs to make exploits worth using.
  • The one complaint I have about OS X is the way it handles wireless networks. I can't save the password on the keyring unless the the SSID is being broadcast. What the hell is up with that? With XP, it just works. (Kills me to say that, but it's true.) Hopefully they'll fix it in the next version, but I'm guessing they would rather make it easy for AirPort and a pain for linksys.

    I know disabling SSID broadcast doesn't really give you much security, but I live in a townhouse. Why make it easy?

    • Re: (Score:3, Informative)

      by Repugnant_Shit ( 263651 )
      Maybe I don't understand your problem, but I have a WiFi network at home that does not broadcast its SSID, and uses WPA-PSK and MAC filtering for additional security. My PowerBook and PPC iMac both use this network, and I never have to type a password in. I added my home network to the "Preferred Networks" list in Network preferences.

    • Re: (Score:1)

      by drcagn ( 715012 )
      What's really bad is that it's impossible to differentiate between two APs with the same SSID. My internet connection has gone out, and two neighbors have a network named 'linksys'--one is WEP-encrypted, and the other is open. Trying to connect to the open one mostly brings up a WEP password prompt. Argh, I don't want THAT linksys!
      • Ethernet cable: $5, tops. You may even be able to use the one that currently connects it to the Internet, temporarily. Call linksys and find out how to reset the router -- it's going to be a huge pain in the ass, something like "Tuck the antenna under your arm, stick the power cable up your nose, click your heels three times, and say 'There's no place like Slashdot!'" But it will work. Then turn it on, plug your laptop in directly via network cable, and reset. Set a unique name, then throw away the ne
        • I'm not sure his neighbor will let him plug an ethernet cable into his router. Although it wouldn't hurt to ask. ;-)
      • '' What's really bad is that it's impossible to differentiate between two APs with the same SSID. My internet connection has gone out, and two neighbors have a network named 'linksys'--one is WEP-encrypted, and the other is open. Trying to connect to the open one mostly brings up a WEP password prompt. Argh, I don't want THAT linksys! ''

        I suggest that after you go over to their houses and ask for permission to use their networks, you tell them how to change the SSID.
        • I suggest that after you go over to their houses and ask for permission to use their networks, you tell them how to change the SSID.

          Why bother? Just log into their router and change the SSID yourself. Chances are they don't have their client machine set to use a specific SSID either, so they'll never notice a thing.

          As P.T. Barnum might have said, if you can't exploit the foolish and clueless, what are they for?

      • Comment removed based on user account deletion

    • Re: (Score:3, Interesting)

      by SanityInAnarchy ( 655584 )
      WPA is not easy. Why make it difficult on yourself?

      But 99% of my headaches have been solved by simply adding networks I like to "preferred networks". Once I do that, all I have to do is "Turn AirPort On", and I'm connected.

      And while I was travelling with my father, he was using XP, I was using OS X, and I could get on the hotel network in three clicks: wireless menu, Comfort Inn (or whatever), then click "yes" to the agreement from a web browser. It took him a bit more time, and my mother's computer can

      • Re: (Score:2)

        by Burz ( 138833 )
        The wireless GUI in XandrOS 4 is similar in function and capability to the one in Windows XP, with its own system tray icon/menu. You can select networks, store passwords, configure WEP and WPA, etc. Its the absolute best there is for wireless in Linux right now.
      • A somewhat tangential, though hopefully helpful, addendum to your post is that OS X's Location feature makes life easier still. Adding wireless network SSIDs to your preferred networks is fine and all, but TCP/IP network settings aren't mated to a wireless network. For example, if you store TCP/IP settings for network1, the TCP/IP settings for network2 will be overwritten. Locations are the solution to this problem, and let you associate a set of layer 3 routing preferences with a layer 2 network. Or you co

    • Re: (Score:1, Insightful)

      by Anonymous Coward
      Wow, obviously you don't deal with wireless a lot outside of your own personal computer. I work in a college IT dept and trust me, OS X is infinitely better about dealing with wifi than Windows. The campus uses LEAP for authentication (don't ask) and it's always a huge pain in the ass for a lot of our students who bring in their Windows laptops because the built-in Windows wireless utility does not support LEAP, which then forces us to download and install new drivers and figure out exactly what we need t
      • Yeah I tried that, but the only way I could get the "save password to keychain" checkbox is if the linksys was broadcasting it's SSID. If the checkbox would show up when the SSID wasn't being broadcast, then OS X would be much better IMHO. I thought I was imaging things, so I did some tests and SSID on == checkbox to save password, SSID off == no checkbox. This was with WEP encryption.

        I guess if I have only one gripe with OS X, it's doing pretty well.

    • With XP, it just works.

      I don't know about your keychain problem, for me saving passwords for wireless networks without broadcast SSIDs works just fine. But XP "just works"? You must be kidding. XP doesn't even do WPA out of the box, you have to install shitty "tools" which come with the wireless adapters just because XP only has WEP (a.k.a. 0wn3d-in-30-seconds).

      That said, I must say that the easiest wireless install I performed was on my Linux box, followed by the Powerbook I'm typing this from. Plug in ada

  • Liar, liar, pants on fire.

    This is, obviously, Apple's Enterprise-grade Security and Communications teams in action. Bravo!

  • Knowing Apple... (Score:2, Insightful)

    by Myria ( 562655 )
    ...they've probably had a fix for a month but have spent the rest of the time scrambling the executable so you can't "bindiff" them to figure out what has been changed.

    Microsoft won't release a patch for a flaw they find themselves until someone else finds it because of the bindiff risk. They typically just fix it in the next OS, which you can't bindiff anyway because they're too different.

    Melissa

  • Some more interesting Links (Score:4, Informative)

    by LKM ( 227954 ) on Friday September 22, 2006 @03:35AM (#16159475)

    As always, daringfireball.net has an interesting article on this [daringfireball.net]. And The Macalope [macalope.com] chimes in, too, with a link to an article by Glenn Fleishman [wifinetnews.com]. Enjoy.

    • Re: (Score:2)

      by Ilgaz ( 86384 )
      If there is a single "neutral" IT publication about Macs, I will pay for it. No kidding...

      Daringfireball even tried to "Challenge" with Secureworks about this issue. The "language" of URL may give you a clue.

      http://daringfireball.net/2006/09/lies_damned_lies _and_macbook_wifi_hacks [daringfireball.net]

      I said "neutral" btw, not some sites/blogs calling me a "Maccie" or jump up and down with happiness when Oompla.Loompa story broke. :)

      • If there is a single "neutral" IT publication about Macs, I will pay for it. No kidding...

        There is. Now pay [macjournals.com] :-)

        Daringfireball even tried to "Challenge" with Secureworks about this issue. The "language" of URL may give you a clue.

        Meh. That was a publicity stunt. Doesn't make the articles any less interesting (or any less true :-)

        • Re: (Score:2)

          by Ilgaz ( 86384 )
          Thanks about that publication link,I think it is bad news for my idling colour laser printer ;)

          About the "stunt", yes, I think I am a bit old fashioned and still trying to get used to Web 2.0
  • Me like me new patches, Yarg!!!
  • iPatch

    The release date being so close to Talk Like a Pirate Day is purely coincidental.

  • I don't think there's much of a story here. (Score:3, Informative)

    by Thumper_SVX ( 239525 ) on Friday September 22, 2006 @11:13AM (#16161351) Homepage
    I'm just glad Apple is actually finding bugs in their own code and fixing them in a reasonable period of time.

    I bought a Macbook Pro recently, and it does still have its share of problems. First of all, it's a new platform for Apple so it's almost bound to have a few issues that they didn't predict. Just because OSX has really been running for years on Intel platform, doesn't mean it's optimized for it yet.

    This wireless patch deals with a couple of issues they've found. I installed the patch last night, and I sincerely hope that it does fix the "beachball of death" wireless issue that seems to have hit a fair number of MBP owners myself included. The wireless is pretty damned good, the antenna in the machine is significantly better than my other Dell laptop. However, it's not perfect, and it's known to cause problems in the right (wrong?) circumstances. I can't nail down precisely what those circumstances are, but it will freeze Finder with SBOD problems. Thankfully, EscapePod comes to the rescue for me or it would be that big fat power button of death for my MBP.

    I reiterate... I am a Mac owner and I'm proud to say that Apple is at least proactively fixing their code. Secureworks identified one problem, Apple fixed three. That speaks volumes to me about how serious Apple are about squashing bugs.

  • Easy for Secureworks to prove their exploit now (Score:3, Insightful)

    by lergnom ( 975212 ) on Friday September 22, 2006 @11:51AM (#16161624)
    So . . . now that Apple has patched the code, why doesn't secureworks demonstrate their exploit with an unpatched Apple MacBook? Can they? It seems an easy test. If they have an exploit, show it. The code is fixed.

Slashdot Top Deals

"jackpot: you may have an unneccessary change record" -- message from "diff"

Close