
Why I’m not enabling Bitcode (2015) - walterbell
https://medium.com/@FredericJacobs/why-i-m-not-enabling-bitcode-f35cd8fbfcc5#.pjlo4ndz5
======
MichaelGG
This article was criticised the first time on HN. This part is particularly
fanciful:

>an adversary could find a vulnerability in the LLVM backend to obtain remote
code execution on Apple’s Bitcode compilation infrastructure to inject a
compiler trojan that would affect every single app on the App Store that was
submitted with Bitcode.

That seems like a very much "just so" failure scenario. There's no reason to
think this would open up a huge, recommend exploitable attack surface. And
even if it did, it seems highly unlikely it'd be limited to just apps
submitted with Bitcode.

Same for the backdoor risk. Thinking suddenly Apple would be a target is
silly. There may be good reasons against Bitcode but these security hysterics
don't help the argument.

~~~
lern_too_spel
A compiler provides a very large attack surface. Once an attacker exploits it,
they can directly attack bitcode applications without any further exploits.
Attacking non-bitcode applications requires exploiting certificate validation
as well.

~~~
eridius
One would assume Apple is running the compiler backend in a heavily locked-
down container or VM.

~~~
lern_too_spel
But that sandbox has access to all bitcode apps by necessity. That's the whole
point — once the bitcode compiler has been owned, all bitcode apps are
immediately vulnerable, while compromising non-bitcode apps requires
significantly more additional work.

~~~
gpderetta
Why would it have access to all apps? It only need access to the app it is
currently compiling.

~~~
lern_too_spel
Depends on how it is implemented. If it is implemented as the GGP described,
as a container or VM back end service that compiles multiple apps, that's a
problem. That is precisely the type of problem that would only affect bitcode
apps that the top post didn't think could exist.

------
i336_
I still wonder what the real agenda behind bitcode might be.

It's hard to imagine it's _only_ to make binary size a tiny bit smaller: it
would surely have been easier and faster to have Xcode just categorize each
application's assets and binaries by screen size and architecture, eg by
pushing a ZIP (or whatever) file of separate binaries. This is assuming otool
or a similar utility can't extract individual architectures out of a fat
binary, which I imagine you can probably cleanly do as well.

The app control thing does have me worried, those concerns are undeniable.

------
dguido
As another security expert, I see tremendous security opportunities presented
by bitcode. Apple can start providing high-fidelity feedback to application
developers about security risks in their applications through both XCode and
the app submission process, and may be able to remediate exploited issues on-
the-fly by transforming bitcode.

~~~
bluejekyll
How much could you actually transform with a high degree of certainty that you
don't break the application?

I just don't buy that they is much gain here, for anything. Possibly you'd be
able to swap out assembly instructions for new/better ones that the processor
provides, but do you really want Apple to be giving your customers transformed
application binaries which you haven't tested?

~~~
dguido
> How much could you actually transform with a high degree of certainty that
> you don't break the application?

Compilers routinely "modify" the programs given to them via optimization
passes and the like. This is normal. By having access to bitcode, you're
essentially given a second chance at compiling an application. Forget to turn
on control flow integrity? Want to optimize out a useless API call? You can
fix that.

We even do it far more aggressively by lifting binaries back to LLVM bitcode
with mcsema, then outputting significantly modified binaries with new
functionality. See
[https://github.com/trailofbits/mcsema](https://github.com/trailofbits/mcsema)
for more info. There is breakage when we do this because we can't be sure of
the correct control flow through the application, but you won't have this
problem if you're not lifting back from a binary.

You're also only focusing on the modification part. Don't forget that bitcode
provides a far more suitable target for analysis than binary code.

------
bluejekyll
I wish Apple would drop this entirely. The biggest thing it does is force you
as a developer to use their tools. The actual benefits are very limited.

It would be more interesting if they encouraged source uploads, they built an
entire CI/CD system for testing and releasing your code. Then they could
recompile for anyone opting to use that.

For some background, read this on Rust and bitcode targets for Apple devices
(only appleTV and appleWatch require bitcode, it's optional for everything
else): [https://github.com/rust-
lang/rust/issues/35968](https://github.com/rust-lang/rust/issues/35968)

~~~
dguido
Something I've learned from being a consultant is that there are an infinite
number of possible build system configurations for real applications. Apple
gets the best of all worlds by asking for bitcode since it abstracts any
unique requirements on the developer end but provides them with something of
nearly identical utility as source code.

~~~
bluejekyll
It's not though... its not CPU architecture independent, source code is, or
can be.

