Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Security Businesses Apple

Apple Still Has Not Patched the DNS Hole 296

Steve Shockley notes an article up at TidBITS on Apple's unexplained failure to patch the DNS vulnerability that we have been discussing for a few weeks now. "Apple uses the popular Internet Systems Consortium BIND DNS server, which was one of the first tools patched, but Apple has yet to include the fixed version in Mac OS X Server, despite being notified of vulnerability details early in the process and being informed of the coordinated patch release date."
This discussion has been archived. No new comments can be posted.

Apple Still Has Not Patched the DNS Hole

Comments Filter:
  • by Pfhor ( 40220 ) on Monday July 28, 2008 @07:31PM (#24377283) Homepage
    At the Angrydome [angrydome.org] (which I started out of frustration of this and other things Apple related)

    The only statements we have been able to get out of apple has been from the bug reporting tool. They have stated that they are working on a fix, but it is causing problems in some instances of their deployments, but don't see it as an emergency because there isn't a targeted exploit against their user base.

    They do not need to understand that this is a protocol specific issue, not a code specific issue.
  • by LostCluster ( 625375 ) * on Monday July 28, 2008 @07:43PM (#24377465)
    Mac OS X Server is a high-priced add-on to MacOS that mostly bundles Unix/Linux/OSS solutions for common server tasks, and adds a Mac-pretty-style GUI for everything. It comes with XServe products, but can be added to as low as a Mac Mini. Anybody reading /. would rather run a Linux box, but for those who are used to dealing with Apple products, it can be part of a one-vendor solution.
  • Re:t3h horror! (Score:1, Informative)

    by Anonymous Coward on Monday July 28, 2008 @08:04PM (#24377761)

    Clearly you haven't been in a data centre in a while. At my local co-lo, (while predominantly Dell), I'm noticing there are quite a few xServes dotting the racks. I think MediaTemple is preparing to offer OS X virtual hosting this year too.

  • by Anonymous Coward on Monday July 28, 2008 @08:16PM (#24377873)

    Mac OS X Server is way more than that. It remotely manages and provides services to potentially thousands of concurrent Macs OS X clients and/or effectively manages Apple's XRAID/XSAN storage subsystems. Apple can't walk into an organization and sell them five hundred Macs and very well expect them to use Windows 2008 or Sun servers now can they? Remote software updates, asset tracking, screen-control, web-mail, anti-spam, everything... http://www.apple.com/server/macosx/

  • by actionbastard ( 1206160 ) on Monday July 28, 2008 @08:28PM (#24377999)
  • by jc42 ( 318812 ) on Monday July 28, 2008 @08:38PM (#24378111) Homepage Journal

    Hmm ... I don't think I'd recommend a Mac OSX machine for a server, especially to a small site without technical expertise. When I tried this a couple of years ago, it took me the longest time to figure out why not only that machine, but also a lot of machines in the neighborhood, were so flakey.

    One of the issues was the "Internet Sharing" buzz phrase. If you google that now, you'll find lots of warnings that if you enable this in OSX, it silently starts up a DHCP server. If there's already a DNCP server anywhere on the local network, you now have two of them battling it out, and the symptoms aren't something I'd wish on anyone but a networking expert. Apple's CS people were supremely unhelpful, too. They just made it clear that my problem was that we were running non-Apple equipment on the network, and we would have to shut them off before they could diagnose the problem. Yeah, right. I shut the OSX box off instead, and then started learning what it took to explain why that fixed the other machines' problems. If you're a novice, you really don't need a rogue DHCP server on your network. When the other users figure out that it's on your machine, they will not be very friendly.

    I've also experimented with an OSX web server. The main problem here is that OSX does funky things with file names, starting with their "caseless" feature. This works if everything was developed on OSX. But if you're running a web server, you're probably going to be including things from other machines in the vicinity. If they're not OSX, you'll go crazy trying to figure out what's going on with the file names. And you probably won't be able to fix it.

    The conventional answer you get from the OSX folks is to run the HFS+ file system, which supports case. Well, I tried that. It turns out you have to reformat the disk for HFS+; you can't just flip a bit to turn HFS into HFS+. I did that, and reloaded from backup. Then a couple months later, we had some problems with the disk. I sent it off to Apple for diagnosis, and it came back apparently fixed. Actually, they had replaced it with a new disk, and they copied all our files over. It was formatted as HFS. Oooops! This happened a couple of times with other Macs, so it seems to be a systemic problem. Pointing out to them that you're using HFS+ has no effect.

    And even with HFS+, there are some funky file naming problems that I don't understand. I saw a lot of cases where an rsync would produce strange file names on just the OSX system. Linux, Solaris, *BSD systems, and usually even Windows could rsync back and forth, and they'd end up with the same file names (though Windows would proceed to ignore case and get the wrong files at times). But on OSX, we'd see non-ASCII chars simply garbaged with no obvious pattern.

    So unless you know that you'll never want to copy directories full of files from a non-OSX machine, I'd advise against using OSX as a serious server. It won't work, and Apple's people won't cooperate with diagnosing the problems. (And you'll just get insults if you mention it here on /. ;-). Save yourself the headaches and wasted weekends, and build a server with a real unix-type file system that accepts any bit patterns except '/' and NUL in file names without damaging them.

    (And I have occasionally wished that I could use '/' and NUL in file names. I wonder if there's a system that allows all 256 8-bit bytes in a file name... ;-)

    (And I wonder if there are linux systems that do "intelligent" things with file names. If so, should we also be warning people to avoid them as servers?)

  • by plasmacutter ( 901737 ) on Monday July 28, 2008 @09:18PM (#24378515)

    Given the issues [theregister.co.uk] this patch caused with vista, i'm not at all surprised they're putting more thorough testing through on this.

    Apple does not want to lose it's "just works" reputation my slaughtering internet connections on its platforms.

  • by Anonymous Coward on Monday July 28, 2008 @09:23PM (#24378557)

    Here here, I was administrator of a small network running on OS X server and it was pretty robust. Far easier to set up than the yellow dog Linux they started with and I never got calls on weekends to fix things. Every Linux server I've tried to set up including Red Hat Enterprise Linux 5 required special bits of certain parts of what the heck was that library name again, and then it still didn't work, switch to another distro, same problem different piece. Got tired of switching distros threw out the PC got out the old G4 and set up OS X server in thirty minutes. Threw on Webmin and it was easy to admin too.

  • by Pfhor ( 40220 ) on Monday July 28, 2008 @09:40PM (#24378743) Homepage

    The problem really hasn't been that we are chiding Apple for(we being the OS X Server admins who support these boxes)most of us have gone and compiled our own versions of bind without issue, or being forwarding all recursion to opendns's servers, etc. (And custom installed BIND versions appear to be working fine in the server so far for most people).

    It has been the total lack of response or public acknowledgement of the problem, no timeline for a fix, no patch and or updated knowledge base article on how to resolve the issue.

    Apple just doesn't see it as a big enough issue to state it.

    They still haven't responded to the ARDAgent.app privilege escalation exploit either.

  • by duplicate-nickname ( 87112 ) on Monday July 28, 2008 @09:47PM (#24378805) Homepage

    Same here...I am on AT&T DSL service and the DNS servers are unpatched, and they haven't released patches for their 2wire DSL modems which do DNS proxying (hopefully not caching). I've switch my machines to OpenDNS, but I don't know how an ISP the size of AT&T is not taking this seriously.

  • by MarcQuadra ( 129430 ) on Monday July 28, 2008 @09:58PM (#24378923)

    OK. I'll start from the beginning.

    All the 'internet sharing' devices and operating systems (including Windows XP) will fire up a DHCP server on the LAN they're sharing to, that's what internet sharing is, a single device acting as a NAT/RIP gateway for several other machines. DHCP is quite a simple service (too simple if you ask me, given this particular problem), if you -sometimes- get IPs and other times do not, there's probably a contending DHCP server on your LAN that needs to be hunted down and killed. This is netwoking 101. You never plug the 'LAN' side of a NAT device into a LAN that already has a DHCP server, unless you're sure you know what you're doing.

    Second, regarding the 'case issues'. There is a case sensitive option (that you -can- flip arbitrarily) in HFS+. There are -case issues- if you're doing some kinds of things (CVS checkouts of source directories with colliding names, etc.), but generally nothing that a little understanding wouldn't fix.

    Why on -earth- you would use HFS at all instead of HFS+ is beyond me. That's trying to install Windows on a FAT16 disk. HFS+ has its strong and weak points, but HFS is a dead -dead- dinosaur.

    It really sounds like your mac experiences were from the early 10.x days or even the Classic Times of Olde. I've admin'd several OS X (10.3 - 10.5) servers that do printing, file sharing, VPN, directory services, desktop management, web serving, and even Windows Domain Control, and I've never had a problem with anything you're talking about.

    That being said, I do prefer Linux, but that's just because it's cheap and it runs on anything.

  • by raddan ( 519638 ) on Monday July 28, 2008 @10:34PM (#24379389)
    As of today, we've extricated ourselves from the hell that was Xserves. We purchased a number of these machines because it seemed like an easy and cheap way to get a fileserver going that did both AFP and SMB, was AD-integrated, and could have its file store on a SAN. Well, after much money and a year later, the answer is that Apple very much oversold their ability to integrate into a Windows environment. Here are my gripes:
    • AD-binding is not straightforward. Apple really wants you to run an OpenDirectory, as this allows you to both manage Apple desktops and do single-sign on. If you just want to allow AD authentication on your MacOS X servers, good luck. You're in for a bugfest, with partially-working GUIs and many, many quirks.
    • #1 quirk being: you can't do cross-domain authentication, even if those domains are trusted. This was a showstopper for us.
    • There is only ONE backup application for Xsan that is both a) reliable, and b) has a reasonable support contract. We tried Retrospect (total POS), Veritas (ridiculous wait times for support), and finally, BRU. BRU has a decent product, but the number of MacOS bugs that plague this application make it unreliable and frustrating to use. OSS applications don't handle the numerous HFS+ corner cases. Rsync, which we used for snapshots, routinely hemorrhaged itself on files with extended attributes, despite the fact that this was APPLE'S OWN VERSION.
    • Ever try running a shared AFP/SMB volume on an Xsan? You can't. Surprise, surprise: Xsan is not HFS+ formatted. It uses CVFS, which is a Quantum/ADIC filesystem. Why? Because Xsan is simply a rebadged version of StorNext! So your AFP daemon will spew Mac metadata everywhere which your SMB daemon will not honor, thus totally corrupting your data. Fuck you, Apple. Seriously.
    • You can't modify MacOS X Server files on the command line. Oh, well, you could on 10.4 server; then lock the file and hope you never had to use the GUI again. But on 10.5, even that does not work-- it still overwrites your file; smb.conf is a perfect example. I figured, OK, maybe I should set the immutable flag, but then I started thinking... WHY am I using Apple products again?
    • Apple's enterprise support blows. Sometimes you get an answer, but no matter what, expect a long wait while people on the other end decide whether they want to bother answering your question or not. Want to follow-up on a bug that someone else reported? Good luck. Their bug reporter is terrible. Would it be so hard to run Bugzilla?

    Apple needs to get their shit together. Unless your needs are VERY straightforward, even 10.5 does not solve them. I'll admit that 10.5 has a much nicer server admin GUI, but it does not overcome the problems with the platform.

    We've moved all of these services to CentOS machines. By contrast, getting them working reliably was a walk in the park. Equivalent hardware (hotswap RAID (SCSI, I should add), redundant PSU, fiber channel card, GigE, dual processor machines in a 3U form factor (SuperMicro chassis) come out to about $1k less than an Xserve, on average. And when a part dies, like a backplane, I can BUY THAT PART. With Apple, you have to buy an entire parts kit, which comes with stuff you may not want.

    We now run Samba and Netatalk on CentOS on generic server hardware, connected to our StorNext network. There may be better SAN stuff out there than StorNext (in fact, their licensing department leaves much to be desired-- do they even know how to use their own product?), but we already had a lot invested (three Xserve RAID cabinets). Things run great now, and with the Linux version of BRU, our full tape backup [inexplicably] finishes 9 hours earlier (used to take 60 hours, now takes 51).

    My advice: Apple makes some nice desktops, but their server stuff is only for novices. I went into the experience very optimistic about Apple's stuff, but now I have a very bitter taste in my mouth.

  • by mortonda ( 5175 ) on Monday July 28, 2008 @10:34PM (#24379393)
    ... and that's just exactly the reason people advocate a caseless file system. A folder named templates and another folder named Templates? Are you mad? I'm not really leaning one way or the other wrt caseless fs's, but let's not ask for pain!
  • by dgatwood ( 11270 ) on Monday July 28, 2008 @10:38PM (#24379439) Homepage Journal

    If your server is configured as it should be, the exposure here should be pretty limited. AFAIK, issues with cache poisoning can be dramatically reduced in risk by limiting requests for recursion to hosts within your own network. In environments where the network is untrusted, of course, that's not sufficient, though it is still a good stop-gap to reduce your exposure.

    options {
    allow-recursion { a.b.c.d/xx };
    };

  • by DadLeopard ( 1290796 ) on Monday July 28, 2008 @10:46PM (#24379533)
    They got on my bad side way back when they took DRI to court over the look and feel of GEM (Graphic Environment Manager), that is why You have Windows on the IBM type PC today instead of GEM and Bill Gates is a Billionaire!
  • by mortonda ( 5175 ) on Monday July 28, 2008 @10:51PM (#24379593)

    But recall... this vulnerability is only available to someone who has access to the caching server in the first place...

    No!

    This attack is simply a flood of false answers to a dns query made by either a client or caching server. They *look* like legit answers that beat the actual answer back. Because the legit answer has to be able to get back to the server, the spoofed ones are able to get there too.

    The clients are only vulnerable within their own firewalled network; but a resolving server, even behind a firewall, is vulnerable to the Internet at large.

  • by Anonymous Coward on Monday July 28, 2008 @11:05PM (#24379735)
    As a fellow Xserve admin, I have to agree with every gripe you've got up about OS X Server. For anyone who thinks otherwise, an Xserve with Samba and AFP is NOT a simple drop-in replacement for a Windows file server with AFP. I have nothing personal to add because the parent said it plain as day.
  • by weicco ( 645927 ) on Tuesday July 29, 2008 @12:56AM (#24380653)

    Given the issues this patch caused with vista

    Issues? What issues? I'm not having any issues with my Vista. Oh, you must be talking about the issue with ZoneAlarm... But that's easy: no ZoneAlarm, no issues.

  • by Anonymous Coward on Tuesday July 29, 2008 @02:03AM (#24381119)

    Honestly, did you guys do an in house evaluation of XSAN before you bought it? I worked as a consultant doing OSX server/XSAN stuff for 3 years and we were always very upfront about both the advantages and limitations of both XSAN and OSX server. Stornext as a file system has always performed better with large files, which is why its most often used in a final cut pro video editing enviroment, not neccesarily in a file sharing situation. Direct attached storage is almost always going to be faster for small files/file sharing, and Apple was always clear about that with our customers. Some of them *chose* the flexibility of a SAN enviornment anyways, but they knew they were going to take a hit in performance.

    As far as backup, I would think that you would have been recommended either Backbone NetVault or Atempo Time Navigator by Apple or your VAR. Both of these solutions performed very well and were certified for XSAN by their vendors. BRU and Retrospect were not, the last time I checked. I don't even think their vendors claim to work with XSAN.

    In my experience, the AD plugin has generally worked pretty well for us. There have been bugs in some versions, but overall it does what it is supposed to. Did Apple tell you that it would work for cross-domain auth? There certainly are some AD features it doesn't yet support. This very well could be one of them..

    Does Apple need some work to be a better citizen in enterprise environments? Sure... but in my experience, their stuff works well when used with knowledge of what it can and can't realistically do.

  • by wumpus188 ( 657540 ) on Tuesday July 29, 2008 @03:53AM (#24381657)
    Are you living in 2002 [slashdot.org] or just making this up?
  • by Anonymous Coward on Tuesday July 29, 2008 @04:19AM (#24381795)

    AD-binding is not straightforward. Apple really wants you to run an OpenDirectory, as this allows you to both manage Apple desktops and do single-sign on. If you just want to allow AD authentication on your MacOS X servers, good luck. You're in for a bugfest, with partially-working GUIs and many, many quirks.

    Of course with Mac OS X Server 10.5 you can use augmented accounts and run that OD if you desperately think you need to. Depends what services you're trying to run whether you need to or not, some services just need more directory information than AD can provide.

    #1 quirk being: you can't do cross-domain authentication, even if those domains are trusted. This was a showstopper for us.

    Yes you can. That's what the pretty little checkbox labelled "Allow authentication from any domain in the forest" does. Nifty eh?

    There is only ONE backup application for Xsan that is both a) reliable, and b) has a reasonable support contract. We tried Retrospect (total POS), Veritas (ridiculous wait times for support), and finally, BRU. BRU has a decent product, but the number of MacOS bugs that plague this application make it unreliable and frustrating to use. OSS applications don't handle the numerous HFS+ corner cases. Rsync, which we used for snapshots, routinely hemorrhaged itself on files with extended attributes, despite the fact that this was APPLE'S OWN VERSION.

    There are other backup applications available, I'm not going to go into them now. Rsync can be made to work fine with Mac OS X, depends on your needs of course. Are you trying to backup HFS+ or Xsan? Or can't you make up your mind where your data is?

    If you're backup up Xsan then HFS+ corner cases are pretty much irrelevent given...

    Ever try running a shared AFP/SMB volume on an Xsan? You can't. Surprise, surprise: Xsan is not HFS+ formatted. It uses CVFS, which is a Quantum/ADIC filesystem. Why? Because Xsan is simply a rebadged version of StorNext! So your AFP daemon will spew Mac metadata everywhere which your SMB daemon will not honor, thus totally corrupting your data. Fuck you, Apple. Seriously.

    That's right, it's not HFS+. Uhm, duh? A cluster file system needs to be, well, a cluster file system. Fortunately for you you've just discovered that this creates the magic of a "._" file (AppleDouble extra data).

    Now I've got currently running an Xsan cluster that seems to serve out the same data via AFP and SMB and I haven't had any data eaten. Ever consider that maybe you're doing something wrong?

    You can't modify MacOS X Server files on the command line. Oh, well, you could on 10.4 server; then lock the file and hope you never had to use the GUI again. But on 10.5, even that does not work-- it still overwrites your file; smb.conf is a perfect example. I figured, OK, maybe I should set the immutable flag, but then I started thinking... WHY am I using Apple products again?

    Right, smb.conf. Maybe you could just read the file and look for the big comment noting:

    ; Site-specific parameters can be added below this comment.

    Maybe you could add your customisations below there like you're told to and be amazed that they don't get overwritten. Reading the documentation, that'd be a novel idea.

    Apple's enterprise support blows. Sometimes you get an answer, but no matter what, expect a long wait while people on the other end decide whether they want to bother answering your question or not.

    I've had great enterprise support including contact with engineering teams to fix specific issues I've had. Maybe you should be nice to your reps instead of abusing them in public forums.

    Want to follow-up on a bug that someone else reported? Good luck. Their bug reporter is terrible. Would it be so hard to run Bugzilla?

    Because I know that I want all my confidential data supplied to Apple so they can fix an issue to be public. This just isn't reasonable for any large company. Nor does it make much sense.

    If you're having a bug yourse

  • by Anonymous Coward on Tuesday July 29, 2008 @08:42AM (#24383211)

    GP32 (gamepark - a handheld game console) was hacked.

    lol what? The GP32 and its successor, the GP2X [gp2x.com], are designed to run homebrew, emulators etc [gp2x.de] with 100% raw hardware access out of the box. That's pretty much the entire point of them, given the scarcity of commercial titles.

  • Re:Still vulnerable (Score:3, Informative)

    by metamatic ( 202216 ) on Tuesday July 29, 2008 @12:11PM (#24386975) Homepage Journal

    If only the packages are signed, then an impostor update server could use Apple's older update packages to introduce old security holes into target systems.

    ...if it wasn't for the fact that the system update program won't downgrade the version of any Apple package.

  • by Yaztromo ( 655250 ) on Wednesday July 30, 2008 @03:03AM (#24397861) Homepage Journal

    I found the hardest part is that you get to points where mac is "protecting" you from knowing whats going on. Where windows will give you an error code the mac just says "no". I get really frustrated with it's hand holding attitude.

    This is something you can change in the system. If you have the OS X developer tools installed, just run /Developer/Applications/Utilities/CrashReporterPrefs.app, and change the setting from "Basic Mode" to "Developer Mode".

    Alternately, you can always look up the reason for the crash in the Console application (/Applications/Utilities/Console.app). Or if you prefer to do it the Unix way, grep through /var/log.

    Just because you don't know how to do it, doesn't mean it can't be done :).

    Yaz.

New York... when civilization falls apart, remember, we were way ahead of you. - David Letterman

Working...