This fellow, Loïc Duflot is writing about the Holy Grail (for Crackers) here, you all need to really pay attention. This man is really hitting the proverbial nail on the head.

This is a Public Service Announcement.

Loïc Duflot is on to something here.
I'm hoping to flush out some others that this, or something similarly strange has happened.
This is not about (a Macintosh) Viruses or Trojan Horses in the normal sense.

Welcome to the World of Backdoors ... and we're talking about Macintoshes too:

Legend

" * " = (me) Look at this.

" _ " = (me) I inserted this.

"___________________" = (me) I inserted this too.


On to Mr. Duflot:

___________________

The Quest for Ring 0
(x86 processors)

(Intel chip "ring 0" at Wikipedia)

http://en.wikipedia.org/wiki/Ring_%28computer_security%29

http://www.securityfocus.com/columnists/402

_Excerpts:_

What is SMM?

Loïc Duflot:
SMM stands for System Management Mode. System Management mode is one of the four modes of operation of most x86 processors (Intel Xeon, Intel Pentium, or AMD Athlon for instance). Modern operating systems (such as Linux, BSD, or Windows) run in so-called protected mode. In protected mode, 4 different processor privilege levels (also called rings) are available, ring 0 being the most privileged one and ring 3 the least privileged one. Kernels of operating systems run in ring 0 whereas userspace code runs in ring 3. The set of operations available to ring 3 code is restricted by hardware-enforced security mechanisms such as segmentation, paging, and I/O privilege restrictions. A few security-critical assembly language instructions are also restricted to ring 0 operation. Most software security techniques (PaX on Linux, W^X on OpenBSD, and so on) heavily rely upon protected mode enforced mechanisms. On the contrary, System Management Mode is a 16-bit mode of operation dedicated to system maintenance. Code running in System Management Mode is running with full privileges on the system (free access to physical memory and to peripheral devices). Protected mode security mechanisms (paging, segmentation, rings, ...) are not enforced while in System Management Mode.

Is SMM used to do good things as well?

Loïc Duflot:
As a matter of fact, SMM is routinely used. Operating systems run in protected mode. But operating systems are not meant to be able to handle very specific hardware events ... ( Real Time Clock-related issues , ...

_Enter Cracker injecting spoofs at border machine - think clock - time.timeserver.example_

Thermal sensor signals or other external events, the list is really endless...). In case such an event occurs, the chipset of the system generates a physical interrupt on the motherboard called an SMI (System Management Interrupt). Upon reception of the SMI, the processor will store its entire context and switch to SMM to run the code - which I'll call the SMI handler from now on. By context, I mean most processor registers including control registers, task registers, instruction and stack pointers. It runs the code that has been written by the * BIOS * ...
___________________

Apple uses Open Firmware, and formerly INITs (extensions, in, I think it's called "Supervisor Mode") and Gestalt to talk to the hardware.

http://en.wikipedia.org/wiki/Open_Firmware

http://en.wikipedia.org/wiki/Extension_%28Mac_OS%29

http://en.wikipedia.org/wiki/Gestalt_%28Mac_OS%29

___________________

or motherboard manufacturer to handle the SMI, that is to handle the hardware-specific event that caused the SMI to be generated in the first place. When the handler runs the assembly language instruction "RSM," the processor will restore its entire context and switch back to protected mode.

So, as far as the operating system is concerned,

* nothing happened *. _<-----very important_

The operating system did not notice the CPU switching to SMM and back to protected mode. Code execution in SMM is transparent from the operating system point of view.

What is the link between SMM and SMRAM control registers?

Loïc Duflot:
I said that the security model was that only the SMI handler was able to modify itself. That is only a simplified picture. What the "SMRAM control register" does is first that it enables the ...

*
relocation of the SMRAM base address at physical address 0xA0000. This way, the SMRAM address range is in conflict with the legacy video RAM range. So what happens is that if the CPU is running in protected mode, all accesses to the SMRAM range are forwarded by the chipset to the display adapter.

_BINGO_

And if the CPU is running in SMM, then the accesses are redirected by the Chipset to the SMRAM in main system memory.
*
_Tell me that's not slick, Slick._

When you are in SMM, could you read/write the BIOS code, config and passwords?

Loïc Duflot:
When the attacker switches the processor to SMM, he can write or read any area in physical memory that is reported as writable/readable by the chipset. This means for instance that he can access the BIOS. So there is no way to prevent the attacker from ...

*
updating the BIOS (except if it is stored in ROM) ...

_Apple has an up-datable software ROM in addition to Open Firmware and (on some) hardware ROMs. Remote re-flashing is a normal thing these days, not terribly safe, but accepted._

if he wants to. But remember that updating the BIOS is not a trivial operation. The attacker has to know how it is done and what he wants to modify.

Is Windows vulnerable too?

Loïc Duflot:
Windows NT, XP, Vista are not vulnerable to this attack scheme since there seems to be no way for ring 3 code to request PIO access privileges.

_Windows gets a long overdue attaboy, ... possibly_

In the paper [PDF] I saw a schema with an * AGP bus for the video card.
*

Is the video memory range still the same if the motherboard has just a PCI Express slot and card?

Loïc Duflot:
* Yes, the legacy video RAM range is exactly the same for compatibility reasons. *

Are other architectures (Sparc, PowerPC, ...) vulnerable?

Loïc Duflot: To be able to carry out the privilege escalation scheme, the attacker needs to be able to write to Programmed I/O ports from userspace.
* As far as I know this is not possible on architectures other than x86. * ...

___________________

_Check This_

Debugging Open Firmware Using Telnet

http://developer.apple.com/technotes/tn/tn2004.html

Open Firmware Ethernet Debugging II: Telnet downloading

http://developer.apple.com/technotes/tn/tn2023.html

http://developer.apple.com/technotes/tn/tn2023.html#setup9

Two-Machine Debugging

http://developer.apple.com/documentation/DeviceDrivers/Conce
ptual/WritingDeviceDriver/DebuggingDrivers/chapter_8_section
_4.html

___________________

*
Can we say that this is a hardware feature that can be misused by an attacker? Or should we say that the vulnerability is caused by a bad design of software?

_Here is the money shot, this can be said of hardware in general_

Loïc Duflot:
The "beauty" of the attack scheme is that it does not exploit any software or hardware bug. Each step of the attack can be considered legal in the operating system security policy. So basically we use legal operations to get to higher privileges and to do something that is against the operating system security policy. So who's to blame? The processor for being able to switch to SMM? The chipset for providing the SMRAM control register? The operating system for providing system calls and pseudo-files that allow userspace code to switch the processor to SMM using hardware mechanisms?
*
_Legal, being the key concept. If this doesn't rock your world you're not paying attention_

_end of excerpts_

___________________

" it does not exploit any software or hardware bug ..."
This is key.
He's correct, it "ain't" that.
I need you to think, for example:

Easteregg.

Bend your mind around it, an easteregg FORM of injection from someone that is intimate with the hardware.

Go there, be still and think about it - thinnnnk.

Not necessarily from a vendor, OS, or hardware company, but someone intimate.
And NOT these guys.
Just examples:

http://www.mackido.com/EasterEggs/HistoryOfEggs.html

Famous one by Greg Marriott:

http://web.archive.org/web/19990210085014/http://spies.com/g
reg/eastereggs.html


Another, with graphics:

System 7.5.5 Iguana Flag

http://www.mackido.com/EasterEggs/Iguana.html

In my current Companies case they reflashed firmware in the routers, used a System 7.x laptop (outside) and our own OS 9.1, OS X machines (inside) extensively, with an external Windows based CITRIX App Server.
Firmware revisions on the Xserve and custom tftp booting configs.
Apple Events and Gestalt and a piece of code called _datainit, DataInit, and other custom "_ call" variations.
System 7 inits / extensions and A5 worlds, MacsBug - dcmds, MacOS 9.x (mixture of reserved APIs and voodoo, MacsBug - dcmds, (OS 8 on A5 worlds are emulated only).

The problem here is that this is just part of the equation, the other part is a thing known as (proprietary) API reserved calls:

APIs reserved for Apple
or
APIs reserved for Microsoft
or ...
APIs reserved for embedded systems, it goes on.
These are the "keys to the Kingdom".

Reserved Calls:

Such as these:

Undocumented Windows: A Programmers Guide to Reserved Microsoft Windows Api Functions

http://www.amazon.com/gp/product/0201608340/102-8340628-8662
500?v=glance&n=283155

And this well done book that speaks on hardware hacks:
(Win and *NIX)

ROOTKITS, Subverting the Windows Kernel
By: Greg Hoglund and Jamie Butler
at:

http://www.rootkit.com/

I had a guy that basically said "I'm calling bullsiht", I handed him this book - I haven't seen or heard a word from him since, or my book.

http://discussions.apple.com/message.jspa?messageID=2278271#
2278271

^The discussion group will rotate it off eventually - 5/12/06.^

"AAPL,Gossamer" (and others).
I ran across this, and several more last year - these are quite interesting.

Why does this concern you? (no matter what hardware you run)
What this is, is equivalent to walking on water in the programming world and has been quite the big secret.
OpenSource won't save you. This won't be patched (except at the application level) unless the reserved APIs are changed and former inside developers have their memories wiped clean - these are the back doors, always has been.

Ghost in The Machine.
You have (most any) Macintosh on the internet. Bad Guy(s) sit with border machines watching the bits fly by, waits for the network to update and refresh -they inject a mixture reserved calls and proprietary voodoo (or exploit), they can "update" your disk drivers, setup a PlayMem or a hidden RAM disk made from the graphics card memory / flash partition / font world space to call to the hardware. This can be quite subtle.
Debuggers are imported or captured, transformed (or not) and used against you (as a weapon) the run time libraries can be replaced with custom versions (your programs refer to these, DLL, OLE, Libs etc,)
If they have the time the OS can be rerouted through hard / soft links (aliases, if clicked on crash the machine) to custom hidden Libs for a total own-age.
The thing is, it is totally invisible. You won't see them until or when they let you - a real ghost in the machine.
Encryption is moot.
Hardware trumps root / Admin every-time.
Battle's over and you had no clue.
In this case, IF you were to catch on, disinformation is your only option.

This type of thing happened to 2 Companies I worked for in 1997 and again in 2005, both times we got proof (I found the personality signature of the crack were very similar), at first we didn't quite understand the full ramifications of what we had. Some of us didn't want to sound conspiratorial or crazy to the others.
In the first case a few beers cured that, and the gloves came off, we, at one point collectively took a breath and said "Awwwwh you can't do that".
The print outs said "Yes they did".
Those print outs were hard won, two months of fighting a machine (I siht you not).

Every time I brought up what we had (pretty much) concluded to "professionals" I , we (it) got called everything from "operator error to your imagination".
We (I) stopped bring it up.

I don't claim to have all the answers or all the proof, but I know what I know, and I know there are people out there like me that are loath to bring it up, same as me.
I will not get in to a flame contest here nor have a battle of "wits", take this for what it's worth to you.
I've been called all sorts of things, don't bother with potshots.
I don't care.

I WOULD be interested in hearing thoughts, corrections, from former programmers for Apple on how this works. Such as some of the MacHack guys from '88 through '93.
Any Blue Meanie
Dr. Waldermar Horwat
Jeff Walker and his great IABE hack
John Norstad and what was that "evil disk hack" in '93 about?
Greg Marriott, just because I like his style (Math is Hard).
Dean Yu
or anyone with a "kill Deans INIT" sticker
:-)
and the IRMan writer (is that UHF yet?)
These, and folks from this era I'll listen to. Tell me I'm crazy and I'll toss the printouts.
I want a real discussion and I want to know.
Correct my errors.

And finally.

You say, Why you?
I don't know, for the machines? I really don't know.

Loïc Duflot is what, a year and a half in to this?
Good on him. I'm really pleased folks like him are discovering these "keys" I hope he continues to uncover the rest of this story.

hylas

hylas[|at|]operamail[|dot|]com


[ reply ]

Link to this comment: http://www.securityfocus.com/comments/columns/402/33600#33600