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."
Purpose? Easy... he makes money by promoting himself.
If you check out his web site, it seems that he's trying to maximize advertising revenue. Not only does he have many ads, he also has many Amazon referal links. In addition, he is directly selling advertising:
From his website:
Want to advertise on the Security-Protocols website?
Below are our rates:
Banner Advertising:
10,000 impressions = $75
20,000 impressions = $135
30,000 impressions = $180
Quicktime is much more than the Player. It is a very rich API that lets you do some great things, albeit often with some suffering, as it is getting a bit old...
Even if you use VLC (I do), there's no chance of escaping Quicktime.
The truth is the Intel processor is a lot more prone to buffer overflow attacks
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.
And building your own PC teaches you absolutely nothing about discovering vulnerabilities.
Back in 1999, LinuxPPC decided to mock Microsoft's putting a Windows 2000 machine on the internet to see who would break into it by putting their own up and saying that whoever cracked it first would get the machine.
Their machine had a default install, with default sets of applications.
It took months before anyone cracked the machine. When it was cracked, the hole used to do it was a well-known buffer overflow that had widely known x86 exploits at the time they put the machine up. An Intel machine treated that way would have been instant toast. What took time was that nobody had written a PPC exploit. Therefore none of the automated tools that the script kiddies had would crack the machine.
Sure, for someone knowledgable, it wasn't a hard transition. But the major outside security threat for most of us is not from someone knowledgable, it is from people who are not knowledgable using tools written by people that are. Those people are NOT going to be able to make the transition easily.
It used to be that people would write an application for Windows then recompile for Macs. The result is that the exploit that worked against a Windows version of the application would likely not work on the Mac version. Since there are more Intel machines, odds were pretty good that nobody would get around to writing a Mac version of the exploit for some time. But now the odds are much better that the Windows exploit which the script kiddies are likely to have will work against the same application running on a Mac. Which does make the Mac less secure in practice going forward.
I love it when 13-year-olds post on Slashdot!
I don't think PPC is different from x86 this way, but on HP Unix machines (don't remember the CPU), the stack grew the opposite direction. This meant that stack buffer overflows of buffers declared last in their functions (which is pretty common) would overflow directly into unused stack space, rather than into the stack frame's return address. So the attacker's data would go into an area that had undefined data anyway. I've had the exact same source code (with a buffer declared too small) overwrite a local variable on Linux, while it caused part of the buffer to be clobbered by a function call on HP/UX.
The OS is limited in its choice of stack direction by the opcodes the processor has for push and pop, and the way it handles the stack when taking an interrupt (as well as calling conventions that libraries expect to use).
I don't think PPC is less safe than x86 in this way, and I doubt OS X is full of flaws that aren't exploitable on the original architecture, but it's not completely irrelevant.
There are processor architectures that make stack overflows orders of magnitude harder. For instance, processors with a grow down stack architecture are way easier to exploit than processors with a grow up stack architecture (grow down means that a forward memory copy can overwrite the return address thus enabling the attacker to control the return address, that's a classic buffer overflow).
There are other processor features that make stack overflows harder, NX being a classic example (also mentioned above). The processors calling convention can also help - if your processor operates with three stacks, one for parameters, one for local data, the third for data flow, it renders the return stack immune from overflow of local data buffers, and mitigates the damage that can be caused by an overflow.
So yes, buffer overflows are a software problem. But the damage that they can cause is strictly a processor architecture issue.
Wow. That was the best you could do, combing through past articles over a two-year span.
A virus which requires telnet to be on (it's off by default), another that requires ssh to be turned on (ditto), and a third which requires physical access to the machine.
All of which were hyped up on slashdot as if Mac users actually had a reason to be worried, when almost all of them did not.
Thanks for proving my point.
Information wants to be anthropomorphized.