[PATCH] Adding diversity for security
Alp Toker
alp at nuanti.com
Fri Jan 24 21:58:17 PST 2014
On 25/01/2014 05:04, Sean Silva wrote:
>
>
>
> On Fri, Jan 24, 2014 at 10:30 PM, Alp Toker <alp at nuanti.com
> <mailto:alp at nuanti.com>> wrote:
>
>
> On 25/01/2014 02:54, Sean Silva wrote:
>
>
>
>
> On Fri, Jan 24, 2014 at 3:33 PM, Alp Toker <alp at nuanti.com
> <mailto:alp at nuanti.com> <mailto:alp at nuanti.com
> <mailto:alp at nuanti.com>>> wrote:
>
>
> On 24/01/2014 20:20, Stephen Crane wrote:
>
> On Fri, Jan 24, 2014 at 10:58 AM, Daniel Berlin
> <dberlin at dberlin.org <mailto:dberlin at dberlin.org>
> <mailto:dberlin at dberlin.org <mailto:dberlin at dberlin.org>>> wrote:
>
> On Thu, Jan 23, 2014 at 7:07 PM, Alp Toker
> <alp at nuanti.com <mailto:alp at nuanti.com>
> <mailto:alp at nuanti.com <mailto:alp at nuanti.com>>>
> wrote:
>
> It's a killer feature for anyone who has to
> support
> copy protection
> mechanisms in commercial software.
>
> For exactly how many seconds will that last? :)
>
> Software "cracks" are smart enough to find and
> patch
> patterns even when
> binaries change between releases, but nops and
> register shuffling will block
> the kind of automated "farming" organised
> criminals use.
>
> A feature that's so easy to deploy (just switch
> compiler flag every point
> release) is a valuable tool in giving the edge
> back to
> individuals and
> companies who have to earn some or all of
> their living
> through commercial
> software.
>
> Honestly, I think you are seriously overselling
> it, but
> that's not the
> main point i want to address:
>
>
> Who is going to be deploying this? If
> nobody is
> deploying, then how do we
> know it will be maintained? It seems like the
> initial patch submitter has
> already jumped ship on this patch; doesn't
> exactly
> inspire confidence.
>
>
> Clearly the two use cases are copy protection and
> security through obscurity
> so genuine users aren't going to be at liberty
> to join
> an open debate here.
>
> This I seriously disagree with. Even on the GCC
> mailing
> lists, there
> were plenty of people who were copy protection
> folks who
> spoke up
> about features that were going to be deprecated or
> added.
> The idea
> that "there are plenty of users, but they can't speak
> here" seems a
> bit suspect to me. Saying "this feature would be
> useful
> to us" is not
> something that harms either of the sets of users
> you are
> talking
> about, since it's completely and totally obvious
> that they
> are doing
> it anyway. There is no obscurity at all
>
> I think copy protection is a bit off-topic, but an
> interesting
> idea. I
> would like to point out that we were originally not
> targeting
> this at
> copy protection, and I think defending against code-reuse
> attacks is a
> much stronger use case and a better fit. Creating
> differing
> binaries
> could have interesting uses for watermarking, but we
> really
> haven't
> thought about that much. However, by creating
> unpredictable
> binaries
>
>
>
> Hi Stephen,
>
> That's a good observation. Clearly there are multiple use
> cases
> for the feature which is a good indicator that it has a
> place in a
> general-purpose backend like LLVM.
>
> I don't want to trivialise your work and its significance
> in the
> security field, but if I can get a few nops out of it that's
> already something that makes my life easier so I'm willing to
> support the effort and put in resource from our end (both as a
> commercial entity, and personally as a developer on the
> project)
> if we decide to go with this.
>
> There's every indication that a little unpredictability
> will go a
> long way to preventing the simplistic binary patching used in
> production-line software piracy operations. If we save 100
> units
> from now to 2015 that already justifies the time we'd put into
> helping maintain the code with you upstream.
>
>
> Hi Alp,
>
> There seems to be significant disagreement whether what you
> describe is actually a real threat at all.
>
>
> Yours is the first disagreement I've seen.
>
>
> C'mon man. Nadav, DannyB, and Joe all pretty much said "this isn't
> going to work" for copy protection.
>
>
> If the contents of two similar builds A and B are made to vary
> then the binary patch developed for A will fail to apply to B
> without some degree of effort or analysis.
>
> Similarly if I share a developer preview of A with a third party
> and it shows up online, this gives me a good shot at guessing who
> did it and not trusting them next time round.
>
>
> It seems that for the use case you describe, there are so many simple
> ways to accomplish what you want that it is almost meaningless to
> represent this use case as a compelling motivation for adding this
> feature. I'm sure we can e.g. have LLD add a build ID or even develop
> a simple purpose-built feature to steganographically encode certain
> information in the binary, or shuffle sections/functions (35 functions
> or sections can be ordered in 35! (> 2^128) ways). I mean even GNU LD
> embeds a .note.gnu.build-id in all the binaries it creates.
Sean, I think you're misunderstanding.
The patch is small, relatively self-contained and be usable as soon as
it lands with a simple compiler flag.
lld is great but it's some way off supporting the full set of x86
platforms. The feature you describe hasn't been written and it'd still
need the PRNG which makes the bulk of the proposed patch.
Your lld feature would exist "just because" whereas the proposed patch
has the potential to share code with other features like the
optimization-by-randomization thread posted recently to the list, not to
mention the original goals of the authors.
The arguments you brought up sound canned and could be applied to
anything else in LLVM like the whole PPC backend ("I don't use that
CPU"), debug info ("I never compile with -g") or the optimizer ("it's
cheaper to buy new hardware!")
I thought we were trying to find a way to unblock the work of
contributors who've been responsive to several iterations of review and
clearly have something to contribute?
>
> These aren't about copy protection -- they're simple properties
> that appear to have real world uses that exceed the original
> intent. They apply equally to Open Source, mixed and proprietary
> builds.
>
> As I see it, the gold standard for a feature is one that has use
> cases exceeding the original specification and intent. It's an
> indication that the feature will serve as a building block for
> other facilities.
>
>
> Could you maybe provide some references or rope in another
> interested party? At this point you seem to be the only person
> getting behind this patch as a "killer feature" for copy
> protection.
>
>
> I think either the statements above are trivially valid and make
> sense, or we've missed something and the use case doesn't hold, in
> which case the patches are blocked again.
>
> I could rope in plenty of people but that doesn't seem like a good
> way to answer the question at hand. We have all the facts and we
> should be able to figure it out for ourselves.
>
>
> This is really not the case. I don't feel like I have enough
> information to make an informed opinion about whether the use case you
> describe even *exists*, let alone whether this is the best way to
> approach it. At this point you seem to be the only person
> participating in this discussion that sees a threat consisting of
> (from what I can gather):
> - "farms", which
> - just blindly apply binary patches
> - the cracks that they apply are basically just naive "sed"-style
> replacements that are trivially fooled by almost any modification of
> the binary
> - that are a major source of lost revenue
How else do you think it happens, some kind of AI?
Alp.
--
http://www.nuanti.com
the browser experts
More information about the llvm-commits
mailing list