Questions are in black. Suggested answers are in red. Other possible answers are in green. (For a perfect score, it suffices to give only the answers in red. The answers in green are optional alternatives, answers suggested by other students, or comments from me.)
Which of the vulnerabilities described below would likely have been avoided if the system had implemented in Lampson's message-passing model?
Malicious Max has planted a malicious Trojan horse in your favorite web browser, unbeknownest to you. This is unfortunate, because you frequently use your web browser to access your bank account online, and Max would like nothing better than to steal your bank balance. Max has already set up the backdoor to silently capture your account number and password; now he needs to find a way to get this information off your computer and across the network back to himself.
List at least three covert channels that Malicious Max could use to leak information about your banking secrets to a colluder at large somewhere in the network. Can you find one that cannot be easily detected by a knowledgeable defender who can passively sniff on all network traffic?
In general, I will assume that the colluder can sniff on HTTP GET requests, or can arrange to host a website that you will visit. With that, here are some possible attacks:
You're the dev lead on a networked multiplayer game, and it's still early in the design process. Two different architectures have been proposed (see below). Which one is likely to have better security properties?
In the first proposal, the software is split up into three components: a network shim (a very small piece of code that opens a socket and translates between network packets and internal data formats), a game engine (a large chunk of code that manages game strategy and evolution), and a renderer (a large chunk of code that prepares gorgeous graphics).
In the second proposal, the software is split up differently: there's a game core (like the game engine, but it talks directly to the Internet rather than going through the network shim), a rendering engine (most of the code of the renderer, which figures out what to draw), and a graphics card shim (a very small piece of code which translates the rendering engine's output into a format understood by the graphics card).
In the above, large boxes represent hundreds of thousands of lines of code; small boxes represent thousands of lines of code; and lines represent connections between components. Because the game listens on a low-numbered port, opening a socket will require special privilege, and so the piece of code that talks to the network (network shim or game core) runs with root/Administrator privileges; the remainder runs under the user's account.
The first proposal is probably better: there is less code
running with privilege, which reduces the likelihood of a vulnerability
that can expose the entire system.
(For instance, buffer overruns in the game engine or renderer will
only affect the user's account, but won't give away root/Administrator
privileges to an attacker.)
In addition, the first proposal would make it easy to build
a network firewall and to filter incoming packets.
In addition, the first proposal would make it easy to build a network firewall and to filter incoming packets.
HTML can be viewed as a crude programming language, with security-relevant features like references to resources (e.g., A HREF links). How well does HTML follow capability discipline?
(Hint: If you're stuck, you could think about the scenario where the user is sitting behind a firewall and viewing HTML content generated by an untrusted server on the outside. Also, keep in mind that following a URL is an action that might have a side-effect: consider, e.g., web interfaces to databases.)
Not very well. Malicious Molly can create a web page with an A HREF link naming some resource that Molly doesn't have access to. This is a violation of capability discipline (designation without authority), and it can lead to confused deputy problems.
Here is a scenario where this could pose a problem.
Company X has a firewall. On the intranet behind the firewall,
there is a web front-end to their sales database. Anyone on the
intranet can connect to the web front-end and issue SQL commands by
filling out a form (which is submitted by a GET method, i.e., when you
click the "submit" browser, your browser constructs a special URL and
sends it via a HTTP GET request to the internal webserver).
Malicious Molly, an outsider, constructs a URL
that encodes a SQL command to delete the entire sales database.
Molly can't request that URL, because the firewall doesn't let
outsiders like her connect to the internal web front-end.
Instead, Molly creates an external web site with an
enticing link ("click here for free Britney MP3's") naming her URL,
and she waits for someone inside the company to click on the link.
Or, if she is especially clever, she spams the entire company with a HTML
email containing an IMG SRC tag naming the URL; if the recipient's mailer
understands HTML email, it will try to grab the inline image when the user
reads this email, thereby inadvertently erasing the company's sales database.
In either case, the database can't tell whether this request originates
with Molly or with an authorized company employee, and this leads
to confused deputy problems.
In short, HTML is inherently susceptible to confused deputy attacks
due to its failure to follow capability discipline.
A few people had some trouble with this question, and might want to
re-visit their understanding of modern capability systems a little bit.
A few people had some trouble with this question, and might want to re-visit their understanding of modern capability systems a little bit.