full-disclosure - Re: Evilgrade 2.0 - the update explotation framework is back

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <AANLkTim5thGnwKUkYsJKMLE_F9N+JBgfk7m_4J=7szGG@mail.gmail.com>
Date: Mon, 1 Nov 2010 15:01:03 +0100
From: Mario Vilas <mvilas@...il.com>
To: Valdis.Kletnieks@...edu
Cc: full-disclosure <full-disclosure@...ts.grok.org.uk>
Subject: Re: Evilgrade 2.0 - the update explotation
 framework is back

It would indeed be vulnerable to that, and you're also right about this
attack vector being quite small.

But IMHO an updates mechanism that signs it's packages it quite easy to
implement, so we're talking about getting a tangible benefit from a small
effort. Preventing the signing key from being stolen is a different matter
entirely - it has to do with the vendor's own network infrastructure
security. Unsigned updates, on the other hand, rely on the client network's
security, which cannot be controlled by the vendor.

In other words, a signed updates mechanism is clearly more secure than an
unsigned updates mechanism, even if none of both can be 100% secure, and it
comes at very little cost. Also, there's no such thing as a 100% secure
system. :)

BTW, I don't think the programmers of each application should be developing
their own signature code. Never code your own crypto, just use what's
available. Also, I believe the operating system should provide the
mechanism, not the application.

On Sun, Oct 31, 2010 at 3:36 PM, <Valdis.Kletnieks@...edu> wrote:

> On Sun, 31 Oct 2010 13:09:27 BST, Mario Vilas said:
>
> > Just signing the update packages prevents this attack, so it's not that
> hard
> > to fix.
>
> Except if a signing key gets compromised, as happened to one Linux vendor
> recently, causing a lot of kerfluffle...  Setting up a proper signing
> system
> involves a certain amount of actual cost and effort.  And every
> organization
> that produces code, be it for-profit proprietary code or free open-source
> code,
> has to make resource tradeoffs.
>
> Is there any actual *evidence* that hijacking "authorized" updates is a big
> enough problem to be worth it?  If each year, 5 of their customers get
> pwned
> by the sort of attack that Evilgrade does, but 50,000 get pwned by "click
> here"
> popups that code signing won't do squat to prevent, is it really worth
> their
> time and effort?  Sure, sucks to be one of the 5, but if they instead spend
> the
> resources to do something *else* to make their customer's lives better that
> would
> benefit thousands rather than the 5....
>

-- 
HONEY: I want to… put some powder on my nose.
GEORGE: Martha, won’t you show her where we keep the euphemism?

Content of type "text/html" skipped

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/