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.
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
