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."
No actual security issues here, just "shellcode" -- compiled assembly -- to do things like print messages, run/bin/sh, or reboot the machine. Unimpressive.
--
TANSTAAFI: There Ain't No Such Thing As A Free iPod.
Re:Boooring...
by
Anonymous Coward
·
· Score: 3, Insightful
Boot from your OSX install cd. You can change the password there.
The paper isn't talking about specific OSX vulnerabilities. It is just an exploration of writing shellcode for the Darwin OS on the PPC architecture, which hasn't gotten much coverage up 'til now.
So far, we OSX users have been able to rely on security via obscurity.. Thanks to fink etc. we have the same vulnerabilities as other unix software, but the stock exploits (which are all sun/x86 targeted) just bounce off. B-root took the time to figure out some of the more fun snafus of PPC shellcode (lots of NULs due to the 32-bit alligned instructions mainly.)
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.
uh oh
by
Anonymous Coward
·
· Score: 3, Funny
Bring on the script kiddies!
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?
Still can't see it...
by
foniksonik
·
· Score: 4, Interesting
I still can't see script kiddies sitting down to do this type of hacking for any length of time... seems like they prefer instant gratification. Maybe if someone much more intelligent were to write up a few cracker's kits with a bundle of preset tools and whatnot... maybe then.
As always, if someone REALLY wants to get in to your stuff, they will find a way. Locks and other security are really only targeted at vandals, not thieves.
-- A fool throws a stone into a well and a thousand sages can not remove it.
Can we PLEASE stop calling it "social engineering" and start calling it "telling lies", cause that's what it is.
-- I am a believer of momentum and curves.
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;
Apple is becoming popular
by
theolein
·
· Score: 3, Funny
At first I had a bit of a wonder as to what all this assembly code was until I realised that it wasn't actual exploits, but ways to implement an exploit once you got past the vulnerability.
The mere fact that someone has started posting this stuff on the net should be reason for all us OSX fans to rejoice: OSX is now popular enough that script kiddies and security types are starting to take notice of it.
Truly a two edged sword.
There are Two Better Ways of Doing It
by
Llywelyn
·
· Score: 3, Informative
You can also enable root from the GUI by opening/Applications/Utilities/Netinfo Manager From there, go under the "Security" menu, authenticate and then select "Enable Root User."
If you prefer the command line then "sudo passwd root" should do the trick and is somewhat more elegant:-)
Here's a link to the original article.
No actual security issues here, just "shellcode" -- compiled assembly -- to do things like print messages, run /bin/sh, or reboot the machine. Unimpressive.
TANSTAAFI: There Ain't No Such Thing As A Free iPod.
The paper isn't talking about specific OSX vulnerabilities. It is just an exploration of writing shellcode for the Darwin OS on the PPC architecture, which hasn't gotten much coverage up 'til now.
So far, we OSX users have been able to rely on security via obscurity.. Thanks to fink etc. we have the same vulnerabilities as other unix software, but the stock exploits (which are all sun/x86 targeted) just bounce off. B-root took the time to figure out some of the more fun snafus of PPC shellcode (lots of NULs due to the 32-bit alligned instructions mainly.)
tell application "System Events" to sleep
I watched C-beams glitter in the dark near the Tannhauser gate.
Bring on the script kiddies!
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 still can't see script kiddies sitting down to do this type of hacking for any length of time... seems like they prefer instant gratification. Maybe if someone much more intelligent were to write up a few cracker's kits with a bundle of preset tools and whatnot... maybe then.
As always, if someone REALLY wants to get in to your stuff, they will find a way. Locks and other security are really only targeted at vandals, not thieves.
A fool throws a stone into a well and a thousand sages can not remove it.
Can we PLEASE stop calling it "social engineering" and start calling it "telling lies", cause that's what it is.
I am a believer of momentum and curves.
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;
At first I had a bit of a wonder as to what all this assembly code was until I realised that it wasn't actual exploits, but ways to implement an exploit once you got past the vulnerability.
The mere fact that someone has started posting this stuff on the net should be reason for all us OSX fans to rejoice: OSX is now popular enough that script kiddies and security types are starting to take notice of it.
Truly a two edged sword.
You can also enable root from the GUI by opening /Applications/Utilities/Netinfo Manager From there, go under the "Security" menu, authenticate and then select "Enable Root User."
:-)
If you prefer the command line then "sudo passwd root" should do the trick and is somewhat more elegant
Integrate Keynote and LaTeX