PortSmash: Yet More Leaks

The drum beat of computer security problems just never ends.  Most of what we hear is just consumer grade dumbness—phishing attacks, misconfigurations, and so on.

But deep inside, there are wonderfully sphincter tightening holes, things that show just how far we are from creating perfect systems (e.g., this, this, this, this, this)

This month, there is yet another interesting security problem identified, tagged “PortSmash” [1].  This particular problem is a side-channel, which apparently can leak information from one program to another.  As they say, “Port Contention for Fun and Profit”.

This one is interesting because it has nothing to do with memory or IO, but rather is a subtle effect of the internal design of the Intel chip and clones.  The nickname “PortSmash” refers to the issue:  inside the processor, there are resources shared by different computations including “ports” to the internal busses.  Since they are shared, activity by one program can interfere with another program that needs the same resource. For example, a program may be slightly delayed at certain points because some other program is running.

These collisions are far out of sight of the program logic, but the research shows that they can be detected.  And they may be correlated with what the other program is doing, thereby subtly revealing potential secrets such as encryption keys!

This is pretty cool, if extremely obscure!

The big picture here is that computer architectures have become miniaturized, but that mainly means that the designs we built in macroscopic modules and systems software in the 1980s are now built in to integrated chips, accessible through simplified interfaces.

So all the potential bugs and side channels have been pushed inside the (almost) opaque insides of these massively complex chips. The chip has many functional units connected by internal busses and complex internal communications.

In the case of PortSmash, the internal architecture is multi-threaded, allowing more than one program to be running at the same time.  Having pioneered multithreading at the high level, I know that it is quite tricky to get right, and inherently involves multiple programs sharing resources. Back in the day, we didn’t even try to deal with timing anomalies or side channels, which are surely rampant in any multi threading systems.  (You want security?  Control access to the system.)

Anyway, nice work all.

I’ll note that the report comes from a research group that has a mission and project to investigate precisely this sort of side channel. So we can expect further examples to come to light.

  1. Alejandro Cabrera Aldaya, Billy Bob Brumley, Sohaib ul Hassan, Cesar Pereida García, and Nicola Tuveri, Port Contention for Fun and Profit. Cryptology ePrint Archive 2018/1060, 2018. https://eprint.iacr.org/2018/1060

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.