Slashdot Mirror
Apple Patch Released, But Is It Enough?
entenman writes "Apple Computer's security update train rumbled into the station with fixes for a whopping 43 Mac OS X and QuickTime vulnerabilities. The Security Update patches 31 flaws in the Mac OS X, most of them serious enough to cause 'arbitrary code execution attacks.'" Unfortunately, InfoWorldMike writes "InfoWorld.com reports that Independent researcher Tom Ferris said there were still holes in Safari, QuickTime, and iTunes that he reported to Apple but were not patched in the latest release on Thursday. Ferris told InfoWorld he is considering releasing the details of the unpatched holes on May 14 on his Web site. He also says he has found new holes in OS X affecting TIFF format files and BOMArchiver, an application used to compress files. He did not provide details about the flaws or proof of their existence."
I'd like to see Apple fix security problems as quickly as possible, but this guy threatening to release exploit information a few days after the first patch to go out after the notification? That seems like they are expecting an awful lot from Apple - certainly they want to take a few weeks to analyze their patch and make sure it doesn't break a bunch of things. Apple should not be forced to make an ill-prepared and possibly buggy patch release due to the threats of this "analyst". If he had given several months of warning I could see the justification, but it looks like he is doing this to get some publicity because he knows Apple won't rush something like this, not to the degree this fellow is demanding.
I work for the Department of Redundancy Department.
I think that this is inevitable. Mac OS X is a desktop OS, desktop customers demand shiny new features and Apple needs to compete with Microsoft in adding such features, otherwise it will fall behind in market share. These new features make for a supremely usable OS, but it means that development is always too fast. Security flaws are invariably human logic errors, and when a lot of new code is written really fast, errors are made. Conversely, take OpenBSD, its pace of development is slow and thorough and due to its comprehensive code audit (which slows development) very few security holes are found in the code. As complexity escalates, so will the number of bugs and until Apple's workforce is replaced with androids (Which I'm sure will have a negative impact on its cool reputation) errors will continue to be made.
Although inevitable, we need not accept that there should be quite as many flaws as there are - Apple is in a uniquely privilege position over microsoft in using the unix permission system and the mature core that mach and FreeBSD provides, it must not become complacent. Increasingly, it appears that Apple is becoming sloppy - There are reports of Apple not using automated bound checking and the such. Such arrogance is inexcusable from any developer, and as Apple's popularity increases poor security will invariably become more of an issue. Its time for Apple to seriously take stock of this issue.
Nothing sucks like a Vax, nothing blows like a PowerMac G4
Bullshit. Buffer overflows are a software problem and have nothing to do with the CPU. The PowerPC would have been just as vulnerable, when running identical code.
PPC makes it much harder (thought not impossible) to run code after overflow since it'll clear the stack.
And building your own PC teaches you absolutely nothing about discovering vulnerabilities.
I'm saying they have (hacked) OSX compatible machines, where previously they didn't.
The fact they are self assembled is just because they are cheap (which Apple computers are not).
I wish people don't just jump to quick conclusions and call "bullshit" without thinking through.
PPC makes it much harder ... to run code after overflow since it'll clear the stack.
Clear what stack? The only meaningful difference between PPC and x86 regarding buffer overflows is that PPC has more registers (including a link register which won't be saved by leaf procedures), and that the x86 CALL instruction pushes its value on the stack.
A buffer overflow would simply overflow some buffer, and be engineered so that it will overwrite the stack frame's return address to call some other code (which is also in the overflowed buffer).
Now on Intel every procedure has a return location on the stack, while on PPC only non-leaf procedures do, but since all computation happens in the context of *some* call stack, there will always be a parent procedure that has a return value that just waits to be overwritten.
I'm not sure how PPC can "clear" the stack, or with what purpose.
Every time a potential breach of OS X security is discovered, it's front-page headline news on Slashdot.
...and every time an actual breach is discovered, it oddly never appears on the front page.
Weird huh?
It's not that there are no vulnerabilities, all complex code contains multiple vulnerabilities, it's that Macs being set up with a user level account as opposed to Windows default admin account are much less liable to being actually exploited. The same can of course be said for most Linux distros which are also set up with a default user level account.
Vista will probably help IF it's ever released and as I read on here on slashot the way Vista handles admin tasks (at least in it's current release state) involves an infuriating number of dialog boxes. I'll stick with my mac for now so I can just get some work done (shrug).
I guess this is what I get for responding to a troll.
Tired of all the isms, don't exploit people as an employer, or a government, mmmmK?
One reason *everyone* is more secure than Microsoft Windows is that only Windows has implemented anything even vaguely as bad as the ActiveX/Windows Desktop/IE integration mess.
On the other hand, just about everyone to some degree or another commits the sin of trusting untrustable files. Even the darling of the security set, Firefox, has an installation mechanism that involves executing files directly from the Internet without a user's explicit request.
Apple has "Open safe files after downloading" compounded by the unforgivable sin of treating things like archivers or installers as "safe" files.
I've written about this before.
On a security level, this is like shaking hands after sneezing, compared to Microsoft's fascination with running barefoot through a "Hot Ward" and snogging the Ebola patients, but it's still unacceptable.
Most organizations (and most people) just don't want to believe exactly how bad it really is when a PC gets infected with malware these days. They don't want to know because if they remain in the dark about it they don't have to do anything to fix it.
If you mod me down, I shall become more powerful than you could possibly imagine.
I'm surprised people still take this guy seriously. He's _not_ a security researcher, in fact a browsing of the bugzilla archives will uncover lots of "bug reports" and "vulnerabilities" that are simply wrong. Check this out (won't work from slashdot, copy and paste into a new tab/window):
o rmat=specific&order=relevance+desc&bug_status=__op en__&id=303433
... posting from work so I'm AC for now ...
https://bugzilla.mozilla.org/show_bug.cgi?query_f
Read through it and you'll see the guy is a complete hack. He even issued an advisory when he didn't even understand the kind of overflow.
I'm so sick of hearing people tout this crap over and over... the truth is that security by obscurity does work, and you just highlighted that it does in fact work by noting that there are far fewer people attacking PPC than x86, that situation is only going to get better not worse, with Apple moving away from the PPC platform.
Ever since my company made it policy to move SSH away from the standard ports, the number of dictionary attacks and exploits has gone down from upwards of 20 a day across all our machines down to zero (0). Even though any automated scanning tool worth it's salt could easily identify that it's SSH running on an obscure port from the banner.
Security by obscurity is enough to break the default configuration of most automated scanning tools, which in turn is enough to stop most of the people out there attacking servers at random.
The great thing about using security by obscurity is that by effectively foiling most automated scanning tools, we limit our focus to only people who are genuinely trying to hack us, rather than just anyone, and can focus on tracking them down and turning them over to the authorities.
Security by obscurity does work, it doesn't devalue your other forms of security, and should be considered a useful and valid part of the arsenal of security defences that can be deployed to protect things.
Anyone who says otherwise has obviously never worked in a situation where their security knowledge actually made any difference. It's obvious that an SSH server getting blasted 20 times a day by attackers is at least 20 times more likely to be hacked than one that's hit 0 times a day, and security by obscurity can make that difference.
Heh, we have yet to encounter even a port scan on our obscure SSH port, let alone any kind of attack, so it's safe to say that script kiddies don't want to spend the time scanning all 65,000 ports on every computer when they can get a similar yield by only harvesting those computers that answer on port 22.
:)
It's also probably safe to assume that if someone has the intelligence to change the port that SSH is listening on that they are also clever enough to keep it up to date and securely configured.
Moving your potentially vulnerable services to a different port is effectively putting yourself in the too-hard basket as far as auto-scanning script kiddies are concerned, but doesn't do anything to stop attackers who are targetting you.
Unfortunately the soft pink human underbelly of your network is the most glaring weak point for attackers targetting your systems, and we can't really firewall their voice-boxes and fingers if we expect to keep doing business.