Carsten Haitzler (The Rasterman)
tizen at rasterman.com
Thu Apr 10 12:16:42 GMT 2014
On Thu, 10 Apr 2014 14:25:48 +0300 Jussi Laako <jussi.laako at linux.intel.com>
> 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.
i am assuming a malicious display server. as patrick said - he didnt' want
weston having access to his pim. that's not effectively possible. if weston (or
any other display server) wants that, it'll get it, if you have ever once
accessed it via a gui app.
a compromised display server via some protocol etc. bug can then be considered
malicious. the same as a compromised kernel - once you have injected some code
in, if it is cleverly crafted it can lay in wait.
> 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 can drive the app - tel it to do whatever a user could.
> 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))
the only way they will get to the display is to go via the display server, so
it's part of it, but you have the same problem with a compromised kernel
anyway. it's just something you trust.
> 3) Service receiving providing challenge and verifying challenge signed
> with smart card
display server can driver the app and all auth the same way a user can.
> 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
it has all access to 1 just as much as the user does. if a smart card is
plugged in, then all the callend.veryfy, if it involes a user, goes through the
display server (pin number, password, etc. etc.) and display server can have
recorded such responses before.
> 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.
the vast majority of apps will not be that paranoid. if a user can do it via
input (touch/keyboard etc.) then the display server can do it.
> But that's still bad excuse to let email service or calculator have wild
> card read access to all data on storage.
not saying it's an excuse. just saying that it's something that is seemingly
dismissed. it is process you have to trust. everything you see is going out via
it and everything you input goes through it (screen/kbd/etc.). you trust it
like you trust a kernel. unlike a kernel.. it can segfault. :)
> If we like, we can make a separate external trusted hardware where
> passwords are input and directly transferred to the gSSO storage without
let's be realistic. that is out of the hands of tizen as software.
here's a great trick. you auth with your bank app. you select transfer, amount
then destination. let's say just when you click "ok" on screen the display
server rapdily click son the bank account number and alters it and THEN hands
on your press to ok. now it just changed the destination of the transfer. if a
user can do it, the display server can do it.
> 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.
you still then need a system compositor. another display server. another
process you have to trust and can be exploited. like a kernel. nothing
> 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
and your bugfix or security update for the display server then makes your apps
cease to run. happy users indeed. and as above. if you compromise the display
server as it runs - in memory, a malicious attack can lurk unseen.
> > 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.
it doesn't mean that a shared point of data flow - be that kernel, or display
server, doesn't have full access to everything. the original remaek ( i don't
want weston to have access to my pim". if it chooses to be malicious, it'll have
all the access it likes. if the kernel is compromised you are also up the creek
without a paddle.
> > 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
> Dev at lists.tizen.org
Carsten Haitzler (The Rasterman) <tizen at rasterman.com>
More information about the Dev