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.
Re:Boooring...
by
andfarm
·
· Score: 2, Informative
Nope. Not unless apache/ftpd/sshd runs as root. (Though, admittedly, sshd does... then again, it's been a while since the last exploitable hole there.) And anyway, anybody could put these bits of "shellcode" together with gcc and 5 minutes -- myself included.
--
TANSTAAFI: There Ain't No Such Thing As A Free iPod.
Re:Boooring...
by
gabebear
·
· Score: 2, Informative
actually this won't let you elevate your privleges, it will let you start bash or anything else as root if you can get this to execute from a buffer overflow from a program that ALREADY is running as root.
The easiest way to get bash/tcsh running as root is to type "sudo su root" and then type your password, then if you want to change roots password you can type "passwd" and viola. This also works on other UNIXs that let you use sudo to execute anything.
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!
Vulnerabilities
by
krisbrowne42
·
· Score: 2, Interesting
You know, it might just be me, but it looks like those need to be run as Root, or be run on vulnerable setuid executables, to be effective.
Just to put it in perspective.
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?
Because when theres an exploit out that lets you 'run code as root', theyre usually talking about shellcode. feed it this and you get a rootshell.
-- Pain lasts, kid. Its how you know you're alive.
Sometimes I think this growing up thing is just pain management-TheMaxx
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.
I suppose this is something we must live with, but it is extraordinarily annoying to have to accept the security evaluation of a pseudonymous author.
Why does it matter who they are? You don't have to "accept" anything; they provide the code, which can be independently tested to see if their claims are accurate.
-- How to solve most of our problems: 1.Lots of nuclear plants. 2.Cure aging.
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.
It's a good thing Chomsky's never been guilty of using three words when one would do.
-- I am a believer of momentum and curves.
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;
Re:Well what do you expect from a Troll
by
coolmacdude
·
· Score: 2, Interesting
If you have access to etc/passwd, then you most likely also have shell access in which case you could just do nidump passwd . and get the hashes just as easily.
--
-You may license this sig for only $6.99.
Re:Well what do you expect from a Troll
by
b1t+r0t
·
· Score: 2, Informative
because X Windows doesn't run OS 9 apps
Aqua doesn't either. Classic does. It's just an app that happens to run under Quartz/Aqua. Way back in the day (System 7 era), there were environments (even one from Apple, I think) that emulated a Mac on a Unix box. And of course they ran under X Windows.
--
-- "Open source is good." - Steve Jobs
"Open source is evil." - Microsoft
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:-)
For the Un*x junkies out there
by
krray
·
· Score: 2, Interesting
I read through this. Read it again. Never did like assembly. Time and again it got back to the same thing it seems.
Turning the set-user-id bit on. Yeah. $ cp/bin/sh/bin/root-shell $ chown 0.0/bin/root-shell $ chmod u+s/bin/root-shell $/bin/root-shell #
Yeah, well, not really (anymore:). Back in the the day this was a _easy_ way to take over the AT&T 7300 Unix system lab. Get root on one machine -- and create a root shell. Dump it to a floppy and you were gHod. Mount it as any user on any machine and execute -- you're root.
Today this shouldn't work (and doesn't per the example above). His "exploit" basically tricks the system into actually making it happen. The key is getting a controllable root suid file on the system....
WITHOUT being asked for a password. Good luck.:)
I can just write a shell script: sudo my_bad_script Email it off and hope people type their password when prompted. Too bad my users don't know root's password -- and they really have no need to be admin either. Benefits of company equipment...
PS: I'd be willing to bet my other nut that this little buffer overflow trick, which is really useless, won't work anymore with the official Panther release.
Re:For the Un*x junkies out there
by
PasteEater
·
· Score: 2, Informative
"WITHOUT being asked for a password. Good luck.:)"
No sweat. Since I have access to the machine (per your last exploit) I insert the Mac OS X install disk, reboot from the CD, and select "Reset Password" (paraphrasing here) to change the password for the admin accounts. It might even set the root password if enabled. If root isn't enabled, I boot back into the system I just cracked, enable root, and set the password. Even if you just have an admin password, you can install anything you want anywhere you want, delete files, etc.
I love me some OS X, but let's be real here. If someone knows what they are doing and has the desire, there is at least the possiblity they can get what they want (whatever that may be). It's a different story when they are trying to do it from accross the country, but if someone has physical access to the machine, you're pretty much cooked.
Just a thought.
-- There are two kinds of people in the world: those with loaded guns, and those who dig.
Re:For the Un*x junkies out there
by
zygote
·
· Score: 2, Insightful
No sweat. Since I have access to the machine (per your last exploit) I insert the Mac OS X install disk, reboot from the CD, and select "Reset Password" (paraphrasing here) to change the password for the admin accounts
Exactly, if someone already has this kind of access to a machine, then why bother with all the other stuff?
-- the future is here, it is just not evenly distributed
- w. gibson
Those 2 or 3 would also be members of the local UNIX User Group. Don Ellis, anyway. But the MUG does have a lot of grey hair. I'm the youngest regular attendee at 32, and my father is the Treasurer.
SecuriTeam has posted a paper on some known vulnerabilities in Mac OS X.
Not true. There are no known vulnerabilities posted in this article. This article is nothing but hacking tools that can be used to search for vulnerabilities and to exploit certain types of vulnerabilities if/when they become known.
-- Trust me. This is an inactive account. Regardless of what the/. bean counters might report.
Slashdot Mirror
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!
You know, it might just be me, but it looks like those need to be run as Root, or be run on vulnerable setuid executables, to be effective.
Just to put it in perspective.
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.
Why does it matter who they are? You don't have to "accept" anything; they provide the code, which can be independently tested to see if their claims are accurate.
How to solve most of our problems: 1.Lots of nuclear plants. 2.Cure aging.
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.
It's a good thing Chomsky's never been guilty of using three words when one would do.
I am a believer of momentum and curves.
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
I read through this. Read it again. Never did like assembly. Time and again it got back to the same thing it seems.
/bin/sh /bin/root-shell /bin/root-shell /bin/root-shell /bin/root-shell
:). Back in the the day this was a _easy_ way to take over the AT&T 7300 Unix system lab. Get root on one machine -- and create a root shell. Dump it to a floppy and you were gHod. Mount it as any user on any machine and execute -- you're root.
:)
Turning the set-user-id bit on. Yeah.
$ cp
$ chown 0.0
$ chmod u+s
$
#
Yeah, well, not really (anymore
Today this shouldn't work (and doesn't per the example above). His "exploit" basically tricks the system into actually making it happen. The key is getting a controllable root suid file on the system....
WITHOUT being asked for a password. Good luck.
I can just write a shell script: sudo my_bad_script
Email it off and hope people type their password when prompted. Too bad my users don't know root's password -- and they really have no need to be admin either. Benefits of company equipment...
PS: I'd be willing to bet my other nut that this little buffer overflow trick, which is really useless, won't work anymore with the official Panther release.
Those 2 or 3 would also be members of the local UNIX User Group. Don Ellis, anyway. But the MUG does have a lot of grey hair. I'm the youngest regular attendee at 32, and my father is the Treasurer.
"Common Sense Ain't" -Unknown
Not true. There are no known vulnerabilities posted in this article. This article is nothing but hacking tools that can be used to search for vulnerabilities and to exploit certain types of vulnerabilities if/when they become known.
Trust me. This is an inactive account. Regardless of what the