1426417
story
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."
Link (Score:3, Informative)
Here's a link to the original article [securiteam.com].
Boooring... (Score:5, Informative)
Re:Boooring... (Score:2, Insightful)
That is, run
Re:Boooring... (Score:3, Insightful)
Re:Boooring... (Score:2)
1. Reboot from the OS X install CD. Go to the file menu once the installer starts. You can reset your password there.
2. Load up the netinfo manager and you can do the same thing if you're actually forgetting your root password and not the admin password. Just authenticate and reset the password.
--T
Re:Boooring... (Score:2, Informative)
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.
There are Two Better Ways of Doing It (Score:4, Informative)
If you prefer the command line then "sudo passwd root" should do the trick and is somewhat more elegant
Re:Boooring... (Score:4, Funny)
you can type "passwd" and viola.
I prefer the violin myself.
JP
Re:Boooring... (Score:2)
Re:Boooring... (Score:1)
Re:Boooring... (Score:1)
In fact, I'm posting this from single-user mode right now.
Re:Boooring... (Score:2, Insightful)
Is it still unimpressive when you realize that these turn any remote exploit into a remote root exploit?
Good thing apple is right on top of those patches, or I'd be a bit more worried.
Re:Boooring... (Score:3, Informative)
Re:Boooring... (Score:1)
I see writes, and exec*s, but nothing that sets the (e)uid.
The only clever thing about these kinds of things is how to avoid 0x00. However, when I saw someone's Alpha stack-smash (Oh's?) about 3 years ago, I realised that any RISC was as exploitable as any other architecture. This PPC one simply loads constant 0x00pq as 0x{00+gh}{pq+ij}, and then subtracts 0xghij. Nothing novel there. The alpha was more interesting as some of the vital instructions h
Re:Boooring... (Score:1)
Yea, that was interesting. I wonder if the processor designers should start checking the reserved fields in some of those instructions and throwing an illegal-instruction trap if they are non-zero. That would seem to make it more difficult to design these bits of code. Makes forward compatibility for object code more difficult too, I guess. (G5+reserved field checking might not run G6 code that defines some of those bits...)
Iz
Re:Boooring... (Score:1)
What's more interesting is how to avoid any non-alphanumeric characters. The x86 ISA permits xor, inc/dec, push/pop, and can be used to create (on the fly) any sequence of bytes, which can then be jumped to (so you don't do your computations in this restricted instruction set, you simply build the real program using it).
I have no idea whether any RISC architectures can avoid non-alphanumeric characters in the opcodes.
If they can then simply avoiding a few reserved fields s
Please Note.. (Score:5, Informative)
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.)
Re:Please Note.. (Score:2)
Re:Please Note.. (Score:1)
PPC shellcode
Copyright 1999 palante
?
YAW.
Use this applescript instead ;) (Score:5, Funny)
uh oh (Score:3, Funny)
I just need to... then I'll be hacked. (Score:1)
On a more serious note, posting shell code out in the open will only encourage amateur crackers to try. The paper should just be shared within community of people researching computer security.
I wonder if this was posted as a retalliation of all them mac news sites
Who? (Score:2)
Re:Who? (Score:3, Insightful)
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.
Re:Who? (Score:1)
Re:Eh??? (Score:1)
Re:I doubt that. (Score:1)
Re:Eh??? (Score:2)
Have you heard of the Blaster worm? how about sobig.f?
Granged, with SoBig, someone has to open the mail, I think? But a clever subject line does not a social engineer make.
Re:Eh??? (Score:1)
I agree.
Mind you, last time I checked, Gore should have been President. No one seems to complain about that anymore. I would wager the consequences are more serious for all of us that a system intrusion in a Fortune 500. Why hack silicon when you can hack human?
Re:Eh??? (Score:2)
None of my mac email programs do this. There may be some but I don't know of them.
So, even if the exploit is created and emailed to everyone, you would still have to be gullible, an idiot - or appropriately socially engineered - to start up the exploit. You'd have to do it yourself by running t
Re:Eh??? (Score:2)
Re:Eh??? (Score:2)
Re:Eh??? (Score:1)
But a clever subject line does not a social engineer make
"""
If the subject line causes the recipient to do some action that achieves your aim, but otherwise without that subject line the action would not have been done, then yes, you have just social engineering. Just because a million people fall for it doesn't mean it's not social engineering.
Sure, the whole issue is complicated by the fact that the action appears innocent (unlike reading out your username and password over the phone), and a stupid f
Re:Eh??? (Score:1)
Re:Eh??? (Score:4, Funny)
Can we PLEASE stop calling it "social engineering" and start calling it "telling lies", cause that's what it is.
Re:Eh??? (Score:1)
Re:Eh??? (Score:3, Funny)
It's a good thing Chomsky's never been guilty of using three words when one would do.
Re:Eh??? (Score:1)
Re:Eh??? (Score:1)
YAW.
Re:Eh??? (Score:2)
Well what do you expect from a Troll (Score:5, Insightful)
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'?
Re:Well what do you expect from a Troll (Score:3, Interesting)
Re:Well what do you expect from a Troll (Score:3, Informative)
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.
Re:Well what do you expect from a Troll (Score:1)
You raise an interesting point. In a spectacularly sad fit of pedantry, I tried googling for A/UX and found http://www.applefritter.com/ui/aux , which gives the lowdown from Someone Who Actually Used It (recently!) on the its integration of MacOS 7 and Unix.
MacOs and X11 ran in separate sessions and the hard disk and RAM were partitioned between the two; you had to session switch between them. The MacOS support relied on a 68000 virtual machine, which I suspect is the kind of trick that is now no longer
Vulnerabilities (Score:2, Interesting)
Just to put it in perspective.
Am I missing something? (Score:5, Interesting)
Re:Am I missing something? (Score:3, Informative)
Re:Am I missing something? (Score:1, Informative)
What the author covers in this document is how to leverage buffer overflows on the PowerPC architecture. Sort of a "see, you can do this on PowerPC too".
Surely, no self-respecting geek presumed that buffer overflow exploits on OS X were not possible, but this is the first proof that they do exist.
So what's the big deal about this news? Well consider that I could go and write a version of "Safari Enabler" which does l
Re:Am I missing something? (Score:2)
While it's small, don't underestimate this. My experiences with Windows have been through jobs, and it seemed like everything I needed to run required me to have Admin access WITHOUT PROMPTING*. On a home computer it's easy to see someone running something and giving it the Admin password, but they would have to have thought it was reasonable to do so - and have the password. (An excellent reason to set up each family member with thei
Re:Am I missing something? (Score:1)
If you have a trojan that can get root privileges, why would you bother using any of the code given in the article? Just do it directly in the trojan
All this article shows is how to write buffer overflow payloads, if you find a buffer overflow in a root process.
Something else you can see from reading the (original) article are a few simple ways to make it harder to use such a payload - e.g. processing a system call could check that the sc operation was specified correctly. However, there are so many way
Re:Am I missing something? (Score:2)
Still can't see it... (Score:5, Interesting)
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.
Re:Still can't see it... (Score:1)
You don't suppose that's why they call them script kiddies do you?
Re:Still can't see it... (Score:1)
"the fittest species will be the one that presides over its own ELECTION"
It seems that the electronic voting machine
companies are owened by Republicans
Eh? (Score:2)
Re:Eh? (Score:1)
Re:Eh? (Score:3, Funny)
Re:Eh? (Score:1)
This is nothing to do with shell programming, this is about getting _to_ a shell from within an arbitrary (exploitable) program (by exec*-ing "/bin/sh").
YAW.
I don't see why this made Slashdot (Score:5, Informative)
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.
Apple is becoming popular (Score:4, Funny)
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.
For the Un*x junkies out there (Score:3, Interesting)
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.
Re:For the Un*x junkies out there (Score:1)
His "exploit" isn't a full exploit.
The point is, suppose you have a suid program which *is* vulnerable to a buffer overflow. Say they find another unchecked buffer in sshd. It's almost guaranteed to happen eventually. The question is, what code do you drop in the buffer? That's what he wrote.
PS: I'd
Re:For the Un*x junkies out there (Score:2, Informative)
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 yo
Re:For the Un*x junkies out there (Score:2, Insightful)
Exactly, if someone already has this kind of access to a machine, then why bother with all the other stuff?
Re:For the Un*x junkies out there (Score:2)
You can stop the aforementioned "password reset" by applying the Open Firmware Password 1.0.2 [apple.com] patch. This patch alters the Open Firmware to require a password to change the boot device.
With that said, someone with physical access to the machine can take the hard drive out, plug it into another mac as a secondary drive, and read all the data off the disk. Nothing short of disk-driver-level encryption can prevent that.
If you w
Re:For the Un*x junkies out there (Score:1)
Opportunity for Apple (Score:2)
It shouldn't be all that hard for Apple to make the 'sc' instruction handler check the other two bytes of the instruction and make sure that they'r
To repeat (Score:3, Insightful)
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.