[liberationtech] Chromebooks for Risky Situations?

Wed Feb 6 09:06:01 PST 2013

Just FYI:

Chrome OS devices are not subject to roll back attacks because the verified
boot does not allow that.  Google has extensive documentation on this, and
you can review the implementation by viewing the source code.  Rollback
attacks were an attack vector they specifically designed to prevent.  In
fact as a chrome OS user this is as much an disadvantage as it an
advantage: updates are forced- you can not go back and bug regressions
which don't effect security but that are annoying can occur and there isn't
anything you can do about that.

Also, it isn't just verified boot an attacker would have to overcome.  The
DM verity means any OS and onboard application code must checksum correctly
or it will never run, this is true at all times.  Realize as well that all
of this code is always running off read only file systems.

Note that the builtin data partition (not executable code, in fact data
filesystem is mounted no exec)  encryption is defeatable in the minimal
sense that Chrome OS does allow users to choose to not have to login when
waking from sleep, so user stupidity allows a small opening here.  Heh-
happened to me.  Lost my chromebook and could not remember if I had left it
"locked" (long story!), but I knew it was asleep.  Finderay have had access
to my login session, albeit og little use since I changed my password and I
believe this deactivated access to current email login, eg.  Also
enterprise administrators may have the option of overriding user choice
here, saving users from their stupidity.

Another interesting point: the onboard ssh client is implemented partially
in javavscript (the terminal portion).  Before you whince, know that Google
argues this is more secure than normal ssh Unix clients because in addition
to all the usual ssh protections, it is necessarily running in a Chrome
sandbox!  They are probably right about that?  I think so.

Finally, I wrote up some stuff on their wiki: you can run in dev mode but
still have fully verified boot and auto update.  This gives the machine a
larger local attack surface (not remote though), but opens access to some
Unix user land such as the onboard openssl which you could use for
additional encryption.

Not too that chrome is devices share well and do while totally protecting
users from each other.

Not a security expert myself.  But I have been administering Unix systems
fulltime for over 15 years.  No question in my mind that these things are
more secure BY FAR than any other off the shelf solution you can buy as a
consumer.  That a normal Unix distro could be made to be as secure is IMO
not true as well.

Google has of course just made Chrome OS the target for their Pawnium
challenge this year.  Should be interesting!

Trever
On Feb 6, 2013 8:31 AM, "Tom Ritter" <tom at ritter.vg> wrote:

> On 6 February 2013 10:52, micah anderson <micah at riseup.net> wrote:
> >
> > Can you say what you mean here? What is SOP in this context?
>
> ChromeOS's 'Apps' are all extensions or webpages.  One can't interact
> with any other do to the standard Same Origin Policy browsers enforce.
>  It's what stops evilco.com from reading your logged in gmail.com tab
> in FF/Chrome/IE/any browser today.
>
>
> > I would be surprised if you actually 'bricked' these systems, since
> > neither operating system you mention involves a procedure that has the
> > risk of bricking a device. I suspect this is hyperbole?
>
> Well, I have a colleague rebuilding a FDE Ubuntu computer right now
> because we can't figure out how to repair its partition table and get
> it to boot without a LiveCD.  It's probably possible, but we're pretty
> technical people and we made the call it would take less time to
> recreate the machine than 'fix' it.  Similarly, I recently paid the
> gentoo tax while upgrading udev and not having a kernel switch turned
> on - wouldn't boot, requiring me to LiveCD it, enable the setting,
> recompile the kernel and replace it.
>
> So bricked in the sense of it's now a brick and might as well be sold
> for parts - you're right, that's hyperbole.  But for a non-technical
> person, with no access to someone to repair a machine for him/her - I
> don't know, I think it might as well be bricked.  They can't fix it on
> their own, and it's not going to boot.
>
>
> >> - Verified Boot, automatic FDE, tamper-resistant hardware
> >
> > All of this reminds me of this post:
> > http://mjg59.dreamwidth.org/22465.html
> >
> > which concludes:
> >
> > "Some people don't like Secure Boot because they don't trust
> > Microsoft. If you trust Google more, then a Chromebook is a reasonable
> > choice. But some people don't like Secure Boot because they see it as an
> > attack on user freedom, and those people should be willing to criticise
> > Google's stance. Unlike Microsoft, Chromebooks force the user to choose
> > between security and freedom. Nobody should be forced to make that
> > choice."
>
> I don't disagree with the notion that Chromebooks, Windows 8, iOS, and
> other examples make you choose between "Insecure and running your own
> stuff" and "Secure and running their stuff".  I completely agree with
> it.  I do disagree with a phrase of your except "Chromebooks force the
> user to choose between security and freedom" - I would rephrase it
> "Chromebooks force the user to choose between freedom and Google's
> stewardship".
>
> My gender-inspecific-nontechnical-family-member is not interesting in
> running after-market app stores or tethering apps on their phone, so
> if security was the only concern I would recommend iPhone because it
> is harder to root.  Similarly, if an activist is not going to run
> third party apps or 'jailbreak' their device (and nobody is going to
> take the responsibility to do it for them and then be full time tech
> support) - choosing a more secure, albeit stewarded by Google/Apple,
> system makes sense.  I know some people don't believe this, and I know
> some people (like RMS) say we should always fight the good fight and
> never give way...
>
> But if you nailed me down and said "Make a computer recommendation,
> someone's life may depend on it." Depending on who their adversary is,
> I would probably not make the Free OS recommendation.
>
>
>
> On 6 February 2013 10:52, Rich Kulawiec <rsk at gsp.org> wrote:
> > On Wed, Feb 06, 2013 at 10:24:28AM -0500, Tom Ritter wrote:
> >> - ChromeOS's update mechanism is automatic, transparent, and basically
> >> foolproof.  Having bricked Ubuntu and Gentoo systems, the same is not
> >> true of Linux.
> >
> > Concur on this point, and wish to ask a related question:
> >
> > Many operating systems and applications and even application extensions
> > (e.g., Firefox extensions) now attempt to discover the presence of
> updates
> > for themselves either automatically or because a user instructs them to
> do.
> > Is there any published research on the security consequences of doing so?
> > (What I'm thinking of is an adversary who observes network traffic
> > and thus can ascertain operating system type/version/patch level,
> > installed application base/version/patch level, etc.)
>
> I don't know of any research to point you to.
>
> Obviously any automatic or manual upgrade process is fraught with
> peril, as it is essentially designed to be an endpoint for remote code
> execution.  It would be nice if Google or Microsoft did a case study
> on how they architected their update systems.  Obviously MSFT's went
> screwy with Flame, but I still think there's lessons we can learn.
>
> To Michael's point, how these systems deal with rollbacks and network
> isolation is interesting.  I've heard that Tor Project's Thandy is an
> implementation of a research paper that covers this and other topics,
> but I can't find a reference.  Maybe someone can find it and provide
> one.
>
>
>
> On 6 February 2013 11:23, Andreas Bader <noergelpizza at hotmail.de> wrote:
> > I think SL, Debian, Suse or CentOS are not less secure than ChromeOS.
> > And if there is a secure problem then you have enough control to fix the
> > system.
>
> I disagree with this.  All of those OS (I'm actually not sure of
> 'SL'?) do not do process isolation.  If I get code execution in FF, I
> can compromise thunderbird.  You are not able to 'fix' this except by
> rewriting the OS or doing some jinky hack to run every app as a
> separate user.  Likewise, every app running is not written to the
> quality that Chrome Browser/ChromeOS is.  Additionally, the OS and the
> applications are stewarded by different people, and the interface
> between those groups leads to bugs.  Put a $100K bounty on exploiting
> a desktop app running in one of those OSs and see how quickly you get
> takers.  And finally, I think most people who say "you have control to
> fix things" forget that the 'you' in this context is a person who does
> not write code (python even, let alone c), does not know what a
> partition table is, does not compile their own kernel, doesn't even
> have a compiler installed, doesn't understand the nuances of security
> - and just needs their computer to work.
>
> -tom
> --
> Unsubscribe, change to digest, or change password at:
> https://mailman.stanford.edu/mailman/listinfo/liberationtech
>

--
Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech

----- End forwarded message -----
-- 
Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org
______________________________________________________________
ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE