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
gnuadam
·
· Score: 1, 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.
-- You say:wq, I say ZZ. Why can't we all just get along?
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.
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...
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.
Precisely where was the privelege escalation in the code? 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 has 0s embedding in them, so the code _had_ to self-modify.
YAW.
--
Your head of state is a corrupt weasel, I hope you're happy.
"The only clever thing about these kinds of things is how to avoid 0x00."
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...)
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 should be realtively easy.
No I'm not going to try, the x86 was mind-bending enough.
YAW.
--
Your head of state is a corrupt weasel, I hope you're happy.
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.)
That's a misstatement of the only real fact in this pathetic document. It clearly states that the NULs make it extremely hard to execute buffer overflows.
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.
What??? That wasn't a Troll. This is a serious point. So the article suggests various means to hack an OS X/BSD system. Big deal. Social engineering is a much superior method for achieving a sinister goal. The fact that OS X is a superb OS for development/engineering/science doesn't conflict with its excellence as an art/design platform. My point was not everyone who uses OS X knows Terminal. It might be smart to teach them about it though.
Whatever.
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
Re:Am I missing something?
by
Anonymous Coward
·
· Score: 1, Informative
Yes, you are missing something, probably because the synopsis wasn't exactly clear on it.
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 little more than trojan as a utility that turns on the Safari debug menu. During installation, I require that you provide your admin password.
I use those escalated procedures to install this program as setuid root. Maybe even on accident.
Then some other clever person, who finds this root-owned, suid program (developed by some perhaps naive Carbon developer who does not know what suid means?) on your computer, uses these simple exploits to convert the time you typed your admin password to install the trojan to get full-blown root on your OS X box.
At the risk of repeating myself, this document simply illustrates that OS X users are not immune to buffer overflow attacks, and that it is good advice to get a full accounting of all setuid-root apps on your system and be certain to ensure that they actually need suid(0) and that if they do, they don't have any buffer overflows.
Re:Am I missing something?
by
NaugaHunter
·
· Score: 1
During installation, I require that you provide your admin password.
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 their own login, BTW.) On a well set up lab or work environment each machine could have a different, unknown admin password that would stop this.
I don't say this is impossible, but the fact is that a) Mac email programs generally ask before executing code, and b) all installers (even those that are javascripted to automatically download when entering a page) that require admin passwords have to ask for them. It's not impossible for someone to just blindly enter it, but hopefully it would make some of them think 'Why?'
*This may have been negligence or incompetence from either the software we used or my various support staffs, but there it is. The point I think was bad wasn't that I had admin rights by default, but that installers could take advantage of that without my even knowing they were running.
-- R: That voice. Where have I heard that voice before?
B: In about 365 other episodes. But I don't know who it is either.
Re:Am I missing something?
by
Anonymous Coward
·
· Score: 0
During installation, I require that you provide your admin password.
If I can get you to type your admin password into my installer program, why do I need a buffer overflow attack? At that point, I'm in! I can install whatever I like and have it run as root.
In fact, why don't I just cache your admin password away somewhere? Then when I connect to my ultra evil back door that I've put into my Safari Enhancer which I got you to install on your machine, I can use the stored admin password to run any process as root.
You don't need a buffer overflow vulnerability for this.
Yes - his test program was just that - a test.
It shows that if a buffer overflow exists in an existing setuid program (e.g. sendmail) then the techniques explained in the article could be used to get a root shell.
Re:Am I missing something?
by
Anonymous Coward
·
· Score: 0
You missed my point. Perhaps the naive programmer who required admin access ended up writing the application's installer to the hard drive as owned by root -- but/group/ or/everybody writeable/, or suid root, or something of that sort. (Check your/Applications folder, you might be surprised at file permissions!)
So you'd install some program, in my example, "Safari Enhancer" that installs as drwxrwxrwx in/Applications. The author of this program is naive, but not nefarious.
Then, some local user, who is not naive, but is nefarious notices that this application, which not only is world writeable, is also likely to be run by an admin user (or potentially even root! Don't log in as root people as a matter of course!)....
So he uses these buffer overflow attacks to rewrite Safari Enhancer, and the moment this app is run by a priveleged user, the local computer has been exploited!
Thanks for the opportunity to explain.
Re:Am I missing something?
by
tricorn
·
· 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 ways to get around things like that (in this case, self-modifying code) that it wouldn't help much. A much better defense is to make stack/data non-executable.
Re:Eh???
by
Anonymous Coward
·
· Score: 0
Your post was moderated "-1, Troll" because there is no option for "-1, Stupid".
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.
Re:Still can't see it...
by
steeviant
·
· Score: 1
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.
You don't suppose that's why they call them script kiddies do you?
I thought I was a pretty big geek, but that article looked like pure gibberish to me.;-) I suspect that my local Mac User Group might have 2 or 3 members who know something about shell programming, but that's it.
Then do something constructive with the knowledge gained. Then you will be a "pretty big geek". So many people consider themselves geeks because they enjoy tinkering with computers at what is realistically, a superficial level.
Take CPU instruction sets, register knowledge of various interconnected VLSI's, logic schematics and protocol's down to the bit level, then you will be what I would consider a geek.
I would suspect that my city would have 2 or 3 members who really know something about PPC assembler.;-)
Re:Eh?
by
Anonymous Coward
·
· Score: 0
So you're saying everyone else in your Mac Users Group knows something about shell programming?
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.
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.
--
Your head of state is a corrupt weasel, I hope you're happy.
...a clever subject line does not a social engineer make
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?
The title of this article is misleading
by
Anonymous Coward
·
· Score: 0
As others have pointed out, this article does not actually document any vulnerabilities in Mac OS X, but instead describes how to exploit a vulnerability (specifically, a buffer overflow/stack smasher)*if* one was discovered. Whoever posted this is rather irresponsible, because he/she/it doesn't seem to have actually read through the article. It basically contains a tutorial on writing and injecting shellcode (essentially, the opcodes for execve("/bin/sh",..), which can be used if someone actually discovered an exploit.
Chomsky called it 'manufacturing consent'. It means the same thing.
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.
Re:I don't see why this made Slashdot
by
Anonymous Coward
·
· Score: 0
Your explanation was needlessly convoluted. The AC above you said it better, and more succinctly.
You state that with sobig, someone would have to open the email - on a poorly designed system that automatically executes an enclosure when the email is opened. That feature in itself constitutes a security risk.
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 the enclosure.
-- - Zav
- Imagine a Beowulf cluster of insensitive clods...
True, and I feel it is horrible design - but we are talking about OS X here right?
-- - Zav
- Imagine a Beowulf cluster of insensitive clods...
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
Re:Well what do you expect from a Troll
by
xcarroll
·
· 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 possible.
But back to the pedantry: it did not run MacOS apps under X11. You could run X11 under MacOs with MacOs's inflexible memory management; or you could run proper X11 with no MacOs.
The author offers a few sentences on Aqua (based on NeXT's Display PostScript) vs X11.
I don't think it's true to say that Classic is 'just an app'. Could Apple have used X11 instead of Display PostScript? Presumably it was possible, if non-trivial, to do. But for machines whose biggest niche is (or is that 'was'?) the graphics/publishing industry, Display PostScript was surely an unsurprising winner over X11.
And since X11 under Aqua is coming along nicely (now in harware accelerated Beta, due for full intregation by the end of the year?) it seems to me we have the best of all worlds: The most beautiful (excuse my language) OS and full power *nix too.
-- 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:-)
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
wirelessbuzzers
·
· Score: 1
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....
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 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.
It's a wee bit lower level than that... This is asm code, it should work on any PPC UNIX-based system with a few numbers changed (like the syscall codes).
-- I hereby place the above post in the public domain.
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
Re:For the Un*x junkies out there
by
Anonymous Coward
·
· Score: 0
That is a simple thing to stop though. Any OS X system where the admin has to worry about people having physical access to the machine should have three things done:
1. Set the open firmware password, which stops the CD trick.
2. Set the password to get into single-user mode, which is an even more obvious way then the CD trick &
3. Put a padlock on the case to keep anyone from using the reset button to get around 1). Duh.
Combined, these pretty much nullify basic exploits that come from a system not being in a locked room.
Re:For the Un*x junkies out there
by
PasteEater
·
· Score: 1
What about: reset-nvram, reset-all? Doesn't that reset Open Firmware?
-- 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
Arkham
·
· Score: 1
The old saying still applies -- there is no security without physical security.
You can stop the aforementioned "password reset" by applying the Open Firmware Password 1.0.2 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 want your machines to be secure, you have to apply the patch, lock the physical machine to the desk, and lock the case closed.
-- -
Vincit qui patitur.
Re:Well what do you expect from proprietary softwa
by
Anonymous Coward
·
· Score: 0
they don't even use X at all! Their display system is a proprietary, closed-source system called Quartz Extreme. In addition to the moral issues involved with closed software, this precludes the user from running X apps. There is an untested and alpha-quality X11 emulation layer available for download, but it is emulation, so programs will be slow. Does this sound like a standards-based system to you?
Oh no, they don't use X? maybe they didn't want a window system that is built for ancient workstations so you can have faster remote access. I've used X on a yellowdog PPC box and it was about as useful to me as the big pile of moldy diarhea I just left in the toilet a few minutes ago.
Quartz is semi-opensource, with its routes in the open PDF format.
X11 is alpha quality? well i've used worse, like WINE. This thing runs all the software you can't get in cocoa or carbon flavors without any hitch that I can identify (I use openoffice.org, and as a liberal arts student, it's done 50+ pages without any problems, even though it was beta half the time!).
And as the other guy who replied to this troll stated: Mach-O is an open technology.. though even the inventor claimed it wasn't necessary.
DRM infringes on civil liberties? Not in and of itself, you [expletive deleted]. If they want to design it to be HARDER for you to pirate it, that's one thing, but the DMCA is totally different than all that.
Oh no, DVD players can't play into a VCR without the copy-gaurd ruining the copy! This MUST be a job for the ACLU..
""" 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 freaking MS exploit is involved that makes such trivial engineering actually effective.
YAW.
--
Your head of state is a corrupt weasel, I hope you're happy.
I think you'll find that he called it "manufacturing green consent furiously", which is 4 words.
YAW.
--
Your head of state is a corrupt weasel, I hope you're happy.
Wrong
by
Anonymous Coward
·
· Score: 0
I see you work for SCO...
I just need to... then I'll be hacked.
by
demonic-halo
·
· Score: 1
Well..
I guess I just need to create a new program with a obious buffer overflow (static buffer), put it in a shared directory, set the UID to 0, then create a guest account, which I would share with the world because I enjoy getting hacked.
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 reporting, ha ha, I'm not vulnerable to worms.
With all due respect to the professor, by saying "manufacturing consent", Chomsky is simply repeating a phrase initially coined by Edward Bernays, the father of propaganda (aka Public Relations).
3. The opcode for sc (system call) is 0x44000002. However, bytes 2
and 3 of the opcode are reserved and therefore not used. With no
other opcodes beginning with 0x44 or ending with 0x02 it is possible
to use any none zero value for bytes 2 and 3 of the opcode without
affecting its operation. The final opcode for 'sc' can therefore
become: -
sc.long 0x44ffff02
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're both zero, instead of ignoring them. The payoff? If you can't make a system call without using a null byte, it becomes much more difficult to write shellcode. Though I suppose clever use of self-modifying code would allow it to be used, it would still be a pain in the ass.
--
-- "Open source is good." - Steve Jobs
"Open source is evil." - Microsoft
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!
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.
To celebrate the occasion of my 1000th post, I will post no more forever on Slashdot. Goodbye.
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.
What??? That wasn't a Troll. This is a serious point. So the article suggests various means to hack an OS X/BSD system. Big deal. Social engineering is a much superior method for achieving a sinister goal. The fact that OS X is a superb OS for development/engineering/science doesn't conflict with its excellence as an art/design platform. My point was not everyone who uses OS X knows Terminal. It might be smart to teach them about it though.
Whatever.
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?
Your post was moderated "-1, Troll" because there is no option for "-1, Stupid".
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 might be stupid. But you AC are stupider! YES!
Social engineering is a much superior method for achieving a sinister goal.
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.
I had a sucky sig.
What??? Offtopic??? I give up. I don't get this /. stuff.
I thought I was a pretty big geek, but that article looked like pure gibberish to me. ;-) I suspect that my local Mac User Group might have 2 or 3 members who know something about shell programming, but that's it.
"Common Sense Ain't" -Unknown
...a clever subject line does not a social engineer make
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?
As others have pointed out, this article does not actually document any vulnerabilities in Mac OS X, but instead describes how to exploit a vulnerability (specifically, a buffer overflow/stack smasher)*if* one was discovered. Whoever posted this is rather irresponsible, because he/she/it doesn't seem to have actually read through the article. It basically contains a tutorial on writing and injecting shellcode (essentially, the opcodes for execve("/bin/sh",..), which can be used if someone actually discovered an exploit.
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.
Highly
Chomsky called it 'manufacturing consent'. It means the same thing.
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.
Yourpointis?
You state that with sobig, someone would have to open the email - on a poorly designed system that automatically executes an enclosure when the email is opened. That feature in itself constitutes a security risk.
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 the enclosure.
- Zav - Imagine a Beowulf cluster of insensitive clods...
Yeah, but with Outlook, all you have to do is have the preview pane open on a Windows box, and you can get infected that way.
I had a sucky sig.
Not to nitpick, but "manufacturing consent" is two words. ;)
True, and I feel it is horrible design - but we are talking about OS X here right?
- Zav - Imagine a Beowulf cluster of insensitive clods...
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.
they don't even use X at all! Their display system is a proprietary, closed-source system called Quartz Extreme. In addition to the moral issues involved with closed software, this precludes the user from running X apps. There is an untested and alpha-quality X11 emulation layer available for download, but it is emulation, so programs will be slow. Does this sound like a standards-based system to you?
Oh no, they don't use X? maybe they didn't want a window system that is built for ancient workstations so you can have faster remote access. I've used X on a yellowdog PPC box and it was about as useful to me as the big pile of moldy diarhea I just left in the toilet a few minutes ago.
Quartz is semi-opensource, with its routes in the open PDF format.
X11 is alpha quality? well i've used worse, like WINE. This thing runs all the software you can't get in cocoa or carbon flavors without any hitch that I can identify (I use openoffice.org, and as a liberal arts student, it's done 50+ pages without any problems, even though it was beta half the time!).
And as the other guy who replied to this troll stated: Mach-O is an open technology.. though even the inventor claimed it wasn't necessary.
DRM infringes on civil liberties? Not in and of itself, you [expletive deleted]. If they want to design it to be HARDER for you to pirate it, that's one thing, but the DMCA is totally different than all that.
Oh no, DVD players can't play into a VCR without the copy-gaurd ruining the copy! This MUST be a job for the ACLU..
Go call Modest Mouse, you Emo bitch.
"""
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 freaking MS exploit is involved that makes such trivial engineering actually effective.
YAW.
Your head of state is a corrupt weasel, I hope you're happy.
I think you'll find that he called it "manufacturing green consent furiously", which is 4 words.
YAW.
Your head of state is a corrupt weasel, I hope you're happy.
I see you work for SCO...
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 reporting, ha ha, I'm not vulnerable to worms.
Every schoolkid knows that's 1.465 kiwis!
With all due respect to the professor, by saying "manufacturing consent", Chomsky is simply repeating a phrase initially coined by Edward Bernays, the father of propaganda (aka Public Relations).
cat
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're both zero, instead of ignoring them. The payoff? If you can't make a system call without using a null byte, it becomes much more difficult to write shellcode. Though I suppose clever use of self-modifying code would allow it to be used, it would still be a pain in the ass.
--
"Open source is good." - Steve Jobs
"Open source is evil." - Microsoft
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