ehenning writes "SecuriTeam has posted a paper on some known vulnerabilities in Mac OS X. It lists methods for developing shellcode based on the PowerPC architecture. They note that there are similar vulnerabilities in Mac OS X and Darwin as in IA32 machines."
Use this applescript instead ;)
by
daeley
·
· Score: 5, Funny
tell application "System Events" to sleep
-- I watched C-beams glitter in the dark near the Tannhauser gate.
Am I missing something?
by
tuxedobob
·
· Score: 5, Interesting
Okay, on page 6 he chown's the test program to root. Now, I just tried to chown something I own to root and it said operation not permitted. This is true in both tcsh and bash. It does of course work if you sudo, or start as root, but if you have root access, why write shellcode to give yourself root access on the same machine? Or is this covered after the first 12 pages?
I don't see why this made Slashdot
by
ZackSchil
·
· Score: 5, Informative
I guess Slashdot is just about as sensationalist as your average Dateline or 20/20. The truth of the matter is as follows for all of you who read the article but still didn't get it.
The document contained bits of assembly code that do all sorts of nasty things once slipped into a system. The code could elevate privileges, stat/stop processes, or reboot the machine. It's scary stuff but nothing you should be alarmed or surprised about. Anyone could harm a machine by writing code, that part isn't difficult at all. I could make an Applescript that wipes out your home directory or masks its self as another application, asks for an admin password, then proceeds to wipe your whole HD and overwrite it with ASCII garbage. Creating malware isn't the problem at all. Do you follow me?
What this guy did was create malware that could be slipped into a system remotely through another security exploit, a buffer overflow for example (a buffer overflow is the same type of bug that caused that whole OS X screensaver crashing nonsense a while back that was promptly fixed by Apple). The reason the article is not a reason for concern is that there isn't currently a well know exploit of this nature for someone to use the code featured in this article. The same "security flaws" exist in almost any modern computer system. The thing is, the code isn't the security flaw, an exploit that allows the code would be. The article names no such new exploit.
Well what do you expect from a Troll
by
xcarroll
·
· Score: 5, Insightful
Not so.
Let's start with the windowing environment, since that's the first thing most OS 9 users noticed when they first moved to OS X. Except they wouldn't have moved if OS X had started with X Windows because X Windows doesn't run OS 9 apps. Oops, there goes the business...
Mach-O is not proprietary to Apple. It came via NextStep from Carnagie Mellon's "Mach" project, and is older than Linux. The Mach project and its executable format is published and is generated by gcc. So in what sense exactly is it not 'open'? Oh, you mean, it's not the same as the one you use?
NetInfo (also inherited from NextStep) does the same thing that NIS+ does on Solaris and yp does on Linux, and for the much the same reasons. Or do you prefer to keep passwords in/etc/passwds where they can be cracked by dictionary attacks?
So I think we can guess that OS X was not so much an answer to 'how do we lock people into a proprietary format' as 'how do you get a solid, compatible replacement for OS 9 out of the door asap given that we happen to have just bought NextStep'?
-- public org.slashdot.Sig getSig() throws NotFunnyEnoughException;
tell application "System Events" to sleep
I watched C-beams glitter in the dark near the Tannhauser gate.
Okay, on page 6 he chown's the test program to root. Now, I just tried to chown something I own to root and it said operation not permitted. This is true in both tcsh and bash. It does of course work if you sudo, or start as root, but if you have root access, why write shellcode to give yourself root access on the same machine? Or is this covered after the first 12 pages?
I guess Slashdot is just about as sensationalist as your average Dateline or 20/20. The truth of the matter is as follows for all of you who read the article but still didn't get it.
The document contained bits of assembly code that do all sorts of nasty things once slipped into a system. The code could elevate privileges, stat/stop processes, or reboot the machine. It's scary stuff but nothing you should be alarmed or surprised about. Anyone could harm a machine by writing code, that part isn't difficult at all. I could make an Applescript that wipes out your home directory or masks its self as another application, asks for an admin password, then proceeds to wipe your whole HD and overwrite it with ASCII garbage. Creating malware isn't the problem at all. Do you follow me?
What this guy did was create malware that could be slipped into a system remotely through another security exploit, a buffer overflow for example (a buffer overflow is the same type of bug that caused that whole OS X screensaver crashing nonsense a while back that was promptly fixed by Apple). The reason the article is not a reason for concern is that there isn't currently a well know exploit of this nature for someone to use the code featured in this article. The same "security flaws" exist in almost any modern computer system. The thing is, the code isn't the security flaw, an exploit that allows the code would be. The article names no such new exploit.
Not so.
/etc/passwds where they can be cracked by dictionary attacks?
Let's start with the windowing environment, since that's the first thing most OS 9 users noticed when they first moved to OS X. Except they wouldn't have moved if OS X had started with X Windows because X Windows doesn't run OS 9 apps. Oops, there goes the business...
Mach-O is not proprietary to Apple. It came via NextStep from Carnagie Mellon's "Mach" project, and is older than Linux. The Mach project and its executable format is published and is generated by gcc. So in what sense exactly is it not 'open'? Oh, you mean, it's not the same as the one you use?
NetInfo (also inherited from NextStep) does the same thing that NIS+ does on Solaris and yp does on Linux, and for the much the same reasons. Or do you prefer to keep passwords in
So I think we can guess that OS X was not so much an answer to 'how do we lock people into a proprietary format' as 'how do you get a solid, compatible replacement for OS 9 out of the door asap given that we happen to have just bought NextStep'?
public org.slashdot.Sig getSig() throws NotFunnyEnoughException;