[Dev] Cynara

Jussi Laako jussi.laako at linux.intel.com
Thu Apr 10 11:25:48 GMT 2014


On 10.4.2014 13:21, Carsten Haitzler wrote:
> all input goes thru the display server. thus it has all the time in the
> world to capture anything it likes. if it's malicious you're up the
> creek without a paddle. the input goes THROUGH it via the display server
> protocol (socket) it actively reads input devices and
> munges/passes/routes data onto gui clients.

Yes, but the idea of gSSO is that you enter your credentials only once 
and then never again. So there would need to be display server buffer 
overflow attack ongoing right at the only time the credential is being 
entered. I would like to assume display server not being malicious, but 
possibly having exploitable bugs.

After that point, all authentication is business between gSSO, 
application and service and display server is not involved in this flow 
at all.

But display server is only one of the many services on the device and it 
is not directly communicating with internet. I'm more worried about any 
services that directly communicate with internet services.

> if a user can input it. the display server can fake it. if ths smart
> card is already plugged in (incredibly likely) it'll work fine.

But you have four parties in the game:
0) Smart card
1) Application talking to service
2) User agent for handling authorization going to smart card (display 
server may be part of this, or maybe not (when NFC is used for example))
3) Service receiving providing challenge and verifying challenge signed 
with smart card

Display server may only be involved in (2), but doesn't have access to 
(0, 1 or 3). Usually application doesn't even directly talk to smart 
card service, but talk to the service instead which in turn triggers 
authorization with smart card.

> it wouldnt need the password. if the paypal app can transfer money (lets
> say any useful app can do things like this as thats the job - to do such
> things for a user), then the display server, if it so chooses, can just
> trigger the launch of the paypall app (while you're not looking and
> screen is off).

That's why I would make PayPal application payment authorization require 
me to show my NFC sticker in my physical wallet. Less 
single-point-of-failure scenarios.

But that's still bad excuse to let email service or calculator have wild 
card read access to all data on storage.

If we like, we can make a separate external trusted hardware where 
passwords are input and directly transferred to the gSSO storage without 
ever involving display server. This at least prevents display server 
from changing any passwords. We could also virtualize display server and 
run a secure one outside virtual jail. PayPal application wouldn't run 
in the virtualized jail, but would only get requests from the virtual 
environment and your malicious display server would be disconnected 
while secure operations are being performed.

A bit like Kaspersky has virtualized environment for running untrusted 
applications. Or like I've done with some, that I have OS in virtual 
machine and when I want to install certain application, I just clone the 
virtual machine, run the application once and then destroy that virtual 
machine clone afterwards.

Also having your display server to be able to maliciously utilize my 
application suggests that my application would exist before the display 
server is flashed to the device. I can make a protection that my 
application refuses to run if any of the critical system components have 
been modified after it was built, I can include SHA512 hashes of every 
OS binary blob in it. I know couple of neat software DRM tricks I could 
utilize...

> the display server is by its sheer nature and the data that goes through
> it, a trusted process that you'd better hope you trust, and if yuou
> don't, then tell me - how do you trust the kernel not to sanoop in on

Still it's not equal to all other services in the system... NTP daemon, 
DHCP client, email or PIM service doesn't need access to my PayPal 
password and shouldn't have any technical means to do it.

> all of this too? if you can trust the kernel, you can grant trust to
> other elements of the system necessary for making it work.

I like to use least privilege scheme. Ultimately I don't trust any 
single system so I prefer distributed multi-vendor based system where 
all different independent systems need to agree before proceeding.




More information about the Dev mailing list