Slashdot Mirror

While I've played with ruby, perl, C and work almost daily in a variety of shells I honestly don't have the background to fully understand what they've offered up here.

From the article (and based on my limited understanding) it relies on the shell and curl being resident in a known memory location? Can someone with deeper OS X internals knowledge explain why the system would always put the shell and curl into the same memory space? This seems to go contrary to what I would expect; that the system allocates memory when a program is executed and that memory can be any from the available pool.

If OS X is indeed always putting certain programs into specific memory addresses, then yes this is definitely a problem that Apple needs to fix now. Otherwise, an attack using this approach is more like firing a gun in a pitch black room and hoping you hit a target that may (or may not) be somewhere in the room. While there is a chance it will work, I would rather spend time picking numbers for the lottery (the potential payoff would be much better).

Their link to the Phrack article http://felinemenace.org/papers/p63-0x05_OSX_Heap_E xploitation_Technqiues.txt is a more interesting read. I can't make any claims that I understand that better but after reading through it, it makes more sense. Exploiting programs that use Apple's Webkit. Whether or not those exploits still exist, I don't know.

Not to mention this: http://felinemenace.org/~andrewg/stuff/rm-my-mac.j pg

And, it sounds a lot like the Andrew Griffiths from this page.

http://felinemenace.org/paper.html

additionally

gwendra

Andrewg does know what he talking about. andrewg has published papers (not on mac security) and is part of some wonderful communities pulltheplug.org and felinemenace.org . I assure you that this machine would of been hacked... with SSH access or not. I think it shows the importance of having patches that minimize possible exposure (i.e grsec/pax etc) that would of decreased the chances of successful exploitation dramatically.... but then again nothing is bullet proof

If you want to do an audit, you should take a look at these tools that "induce" browsers to crash in various ways:

Python port of mangleme it seems to have already found some interesting IE holes.

Check the full disclosure archives for more details...

If you want to do an audit, you should take a look at these tools that "induce" browsers to crash in various ways:

Python port of mangleme it seems to have already found some interesting IE holes.

Check the full disclosure archives for more details...