Slashdot Mirror
Surreptitious Communication via Page Faults
Martin Pomije writes "This is a really interesting story illustrating how a shared resource can also be a communication channel. If you have any interest in software design or operating systems, the Multics web site is worth your time. Tom Van Vleck has obviously put a lot of time into this and deserves credit for making all of this information available. " It's like 10 years old, but it's really interesting.
First off, I for one found it very interesting.
Secondly, any time two people have access to the same area, be it a physical area or shared computing resource, there is the risk of covert communications. The only way to prevent it is to remove access to all but one person.
Multics was designed primarily to share expensive computing resources. Computing resources are much cheaper now, so it is more feasible to prevent covert communications by just plain not sharing. Each person in a hypersecure installation would have their own computer, without even a conventional LAN, with communications between the systems being tightly controlled and monitored.
----
----
Open mind, insert foot.
I found this story http://www.multicians.org/security.html amusing, particulary how the password "encryption" in an early version of MULTICS turned out to depend on a compiler bug.
The easiest way to get a password in Multics was the old "trojan terminal" trick. Multics was usually accessed via crowded terminal rooms, and there was often a waiting list to get on (remote access back then was very expensive and few Multics installations had any remote access). Log in, run your trojan (which put up a fake login prompt), walk away. Someone else jumps on your "open" terminal, tries their personid, projectid, and password, gets 'login incorrect' message (at which point your program surreptuously exits and logs out, having saved the data to a file somewhere), and then they get the "real" login prompt. Classic, simple, almost undetectable!
Of course, that wasn't the holy grail. The holy grail was getting one of the operators' passwords, or somehow executing commands as an operator to create a ring0 gate for you (basically same as creating a suid root /bin/sh). I'm trying to remember whether it was Multics that someone tried the "smart terminal" attack on, or whether we'd already moved to Unix by that time. The TVI912 terminal would transmit the contents of its screen to the remote system when you sent ESC-7. So send a clear screen, the commands to be executed, and then ESC-7 as the payload of a Unix "write" command (or Multics equivalent -- still trying to remember whether Multics had an equivalent, darn it!), and guess what happens? (Oh, make sure to clear the screen again after you've sent the payload!). Of course, after the first time, the operators remembered to turn off messages ("biff n" on Unix) :-).
-E
Send mail here if you want to reach me.
As I remember, System/360 storage keys were associated with large (4K?) regions of memory; they weren't associated with individual words, as tags are on the Burroughs machines (and their successors) and on the PowerPC AS/400's. I tend to think of "tags" as applying to individual words; do storage keys protect down to the word level on S/390?
It's in the PowerPC AS/400's, at least according to Frank Soltis' Inside the AS/400 book - there are tag bits in the extended PowerPC architecture used in the AS/400's.
It's also presumably still in the the Unisys ClearPath LX and ClearPath NX series, which include processors that are presumably the latest generation of the line of machines that started with the Burroughs mainframes.
No, it didn't.
The poster to whom you're responding was mistaken; they didn't use XML, they used SGML.
(Or, as the banner on this site should perhaps read:
Slashdot
YHBT. YHL. HAND.)
Covert communication channels are a security risk in a system that has restricted data which it is trying to limit access to. For instance this would be an issue if you have a multi-user system which contains classified information. This is the kind of thing that is covered in a B2 security clearance.
Covert channels are not a security risk if your question is keeping the wrong person from getting in control of your computer.
Cheers,
Ben
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
here's a real life example of using a shared resource (a 5 1/4" floppy drive) as a communication channel that has worked well for years. In the IS office that this is in (and I'm not naming names cause I know one of their managers reads /.) the main server room is on the far side of a cube farm where the grunts in the IS staff sit. Located in the main server room is a print server with an old 5 1/4" drive that rattles really loudy when you try to access it without a floppy, almost every member of the IS dept has that drive mapped on thier desktop machines. It makes the perfect alarm bell... any time management comes into the cube farm and walks down the side isle then someone will see them and hit refresh on that mapped drive which will ring the alarm in the server room and warn the occupants of the room of managements impending approach... we won't go into why they might need warning... use your imagination. ;)
Back in 1980, my high school had a PDP 11/03 for student use. The operating system was an early version of RT11. We had a binary license, and received the operating system on a set of 8 inch floppies. I spent a lot of time on this machine.
One time I did a disk dump from the raw disk device to the console, and after a few pages of binary gibberish, out came several pages of operating system kernel source code! Apparently, Digital, when it made up the master disk for the operating system binary distribution, reused a floppy that had previously contained operating system source code, and never bothered to zero out the disk. Interesting stuff!
Different problem. TEMPEST is concerned with information leakage via electro-magnetic radiation.
Covert channels are a concern in multi-level secure systems where information of different classifications and compartments are processed on a single system. A process running in a Top Secret context should not be able to send classified information to a process running in a Confidential context.
Mea navis aericumbens anguillis abundat
Actually it is explained really well in Tanenbaum Operaton System book on page 437 in the second edition.
His site is hosted by best.com, probably on a shell machine with alot of other sites. The typical account has a 200MB/day, 25k hits/day limit.
The total amount is compared against the last 24 hours, computed on the hour. Check just after the hour and you may get thru, before he's back over the limit again.
This is just like any other quota system to keep one user from hogging an unfair share of the available resources, in this case bandwidth, hits or cgi cpu cycles.
-- Ryan Watkins vamp@vamp.org http://www.vamp.org/
-----------
"You can't shake the Devil's hand and say you're only kidding."
wasnt this one way to break passwords in some old systems ? you would cycle through the letters one by one and with a page fault you could know which was the right letter at one position. this reduced the work greatly.
The B2 systems I've played with won't even allow you to cut and paste from one window to another that doesn't have the proper level of privs. Keep in mind this isn't as easy as layers as well.
Most B2 systems have several user groups and each are in a different Security Realm. You can be in several Realms and you may be able to copy info from one area to another but generlay you cant go the other way without downgrading the data which of course requires other levels of access. Real access control is not easy to do and is very, very complicated.
When I ran a news server for the AF I used to feed news to a B2 certifed system. I never new if it got the news or not because it never responded. It had a dedicated hunk of hardware that did TCP/IP and simply acked everything. It was like sending bits off into the ether.
So the question becomes, how can I not get caught? Spreading information via covert channels (the technical term for this sort of communication) makes it very hard for said agents to even suspect my actions, and to gather evidence for a conviction.
(Note to my fans in domestic surveillance: only kidding, everyone knows I'm a good law-abiding American.)
Tom Swiss | the infamous tms | my blog
You cannot wash away blood with blood
How's that for slashdoting...
Sorry, temporarily closed
My internet service provider, Best Internet Communications, limits the number of hits and the bandwidth each web site can consume, and my site is past its limit.
http://www.multicians.org:80/limit.html
If you had a file that was write only and you had like a LOT of copies and you wrote some data to the file could you verify that you had written different data by timing the page fault? I cant see any real use for this but it's a new way of thinking about stuff.
How we know is more important than what we know.
I have requested temporary relief from my hit quota. Best.com was pretty quick last time I was slashdotted, hope it's quick this time. They put in tiered pricing a few years back when people put up porn sites on Best's servers: rather than censor, they charge for bandwidth. I've been well served at the lowest tier.
Actually, this doesn't affect most Slashdot users because the operating systems they use have such lousy security that there are far easier attacks than using a covert channel. This applies to all the UNIX variants and all the Microsoft products. (Yes, it does. If it didn't, there wouldn't be new CERT advisories every week.)
There are solutions to the covert channel problem, but people hate them. Applications have to be denied access to an accurate timebase, which means no clock with resolution finer than a second, introducing deliberate jitter into the CPU dispatching, and adding some random delay to I/O operation responses. Forget playing games or multimedia.
The big win is that in a system with mandatory security and covert-channel protection, even if a virus or trojan horse gets access to secured data, it can't get the data out of the box.
I used to develop secure operating system kernels for a DoD contractor. The current state of operating system security is worse than it was twenty years ago. Users will choose animated penguins over security. What passes for "computer security" today is mostly aimed at keeping amateurs from blatantly interfering with servers. And it can't even do that successfully. A serious attack is much more subtle.
In the DoD world, one worries about two main threats. The intelligence community worries about the attacker obtaining some information they have without an alarm being raised. The military worries about the attacker interfering with their systems at a time chosen by the attacker, probably at a key moment of a military operation. The attacker is assumed to have enough resources to duplicate the systems being attacked and to practice on them. There's also the assumption that physical and computer intrusions might be used together.
Enough rant for now. Go read some NSA evaluations of security products.
This actually sounds like just a special case of traffic analysis. Traffic analysis is one thing that you can do if you can intercept but not decrypt your enemy's transmissions. When his signal traffic increases suddenly, you know something is up.
If you really want to be paranoid about signal security, you have to send out a background of boring messages at least as big as your expected peak traffic. You could, for instance, send out messages that said "Ignore me" padded with whitespace (and then encrypted) at periodic intervals. When you actually want to send a real message, you'd substitute your real message for one of the fake ones. Of course this is something that computers are very good for; they can mimic the length patterns of real messages and automatically ignore the bogus received messages.
By analogy, the State and Defense departments could constantly order late night pizzas even when nothing interesting was going on. A more practical alternative would be to have a supply of frozen pizzas and an oven, or even an in-house pizzeria. Sounds like a good excuse to me.
There's no point in questioning authority if you aren't going to listen to the answers.
ftp://ftp.stratus.com/pub/vos/multics/tvv/timing-c hn.html
bah. why repost an article when a URL will do?
Proof Carrying Code is a much better solution than signed binaries. Signed binaries still require you to trust the developer, which is many cases is still not a good idea. See here for more information:
/pcc/pcc.html
http://www.cs.cmu.edu/~petel/papers
I'm really heartened to see that folks are willing to read about discoveries made in the past, learn from mistakes that have been committed before, and stand upon the shoulders of earlier generations, rather than standing in their footprints.
I was able to use Multics for four years in college, and that experience gave me more insight and wisdom than any four years spent with Unix, Windows, or MacOS.
(In the areas of system design, that is! The only graphics expertise I gained from Multics was how to do simple bitmap images using the lineprinter!)
An unapologetic former Multician,
Stan Chesnutt
...and, at least in the older processors only in a segment tagged as a segment whose code should run in "master mode"; even most of the ring 0 code couldn't execute privileged instructions - it could only call small routines in one of those segments (said segments were, presumably, inaccessible outside of ring 0). The entry for "privileged mode" in the Multics site (well, mirror site at Stratus, anyway) glossary says:
Hardware and/or microcode - the GE 645 and 6180 had no microcode; the Multics site glossary entry for the 6180 says:
Networking a VAXstation and a RS/6000 via SCSI! The other stuff is cool also!
A B2 secure rated system requires that a program authorized to read sensitive data must not be allowed to *give* that data to a process with lower clearance. In theory, a trojan which infiltrated the secure levels of a system would possibly be able to read/modify/destroy that data (though other mechanisms exist to prevent that), but not communicate it to an untrusted party. However, with a covert channel such as this, that protection doesn't work.
If anyone's curious, more info on confinement and covert channels is here:
at erights.org
The computer security fact forum
They're called "covert channels" in secure systems work / Orange Book terminology, and it's extraordinarily difficult (actually, impossible) to eliminate them totally --- a case of asymptotic approximation, law of diminishing returns, etc..
The classic tradeoff between probability of detection and bandwidth of the covert channel operates here, but if the amount of data which needs to be communicated is low then the trojan spook always wins against the guardian.
On the other hand, detection of the covert communication is an interesting problem in its own right, because it boils down to the problem of telling the remote party exactly where to find the significant data among gigabits of obfuscation --- effectively the same problem as key exchange in crypto!
"The question of whether machines can think is no more interesting than [] whether submarines can swim" - Dijkstra
The original site is closed due to bandwidth quota restriction.
See alternate location.
-- What you do today will cost you a day of your life.
Rather than shared resources, how about programs posting to Slashdot then reading it:
Program A writes to a random thread.
Program A-2 loads the thread, and moderates up the post, using karma from it's auto-"Linux is not socialist" post feature (such posts are always informative).
Program B (the reciever) loads the thread likewise, using Highest Scores First, and reads the posts marked up to two. It then leaves a "Linux is socialist" post. Invariably, a moderator will find this, take offence, and moderate it down.
Program A will, by continuosly re-loading the thread, notice the new (Score: -1, Troll) post, and will be assured that the communication was successful. Program execution will then continue as normal.
Hmmm...maybe I should patent it.
This article probably doesn't interest most slashdotters, because the OSes that we use aren't designed to protect against these kinds of things. This, of course, stems from the fact that the situations in which we use our systems do not require us to segment our users and prevent them from communicating.
In the DoD, for instance, there are situations where you would want to do this. You don't want to allow someone viewing Top Secret data to have their information leaked to someone who isn't cleared for it.
This is why Mandatory Access Controls were invented. A lot of slashdotters have probably heard of the Orange Book, in which the DoD laid out a method of classifying the security model of computer systems. Unix variants are roughly C-1'ish, which DoD doesn't even certify anymore. OSes with ACLs and such (like NT) are roughly C-2'ish (now whether NT actually gets the job done or not is up for debate). Once you get to the B and A levels, you have Mandatory Access Controls. They are designed to prevent one user from leaking classified data to another person. In a MAC system, you should not be able to "chmod" or "chown" a file to allow someone else to view it.
It goes a little bit deeper, though. You also need to protect against more subtle methods of communication, called covert channels. In a covert storage channel, a user would fill up a disk and another user would be able to tell, or one would write to a file that another had access to read, or one would twiddle a file lock. In a covert timing channel, one user would perform a CPU intensive process and the other user would be able to tell that the responsiveness of the system changed, or the user would perform an I/O intensive application and the other user would be able to tell that his own disk accesses were more or less responsive. In this way, users can communicate via manipulating shared resources.
It's not very sexy, but it is something that DoD and the intelligence community in particular care very much about. As you can guess, these aren't easy problems to solve (if they are solvable at all).
Since the site linked from the story appears to have been slashdotted, here is an alternate link to the same story.
Deven
"Simple things should be simple, and complex things should be possible." - Alan Kay