Why trust any software?

kardan kardan at riseup.net
Wed Aug 7 21:37:46 CEST 2013 

Hi,

thanks for your thoughts and sorry for this copy/paste nightmare. I
tried to fit in my thoughts, but if you think this topic is on the wrong
list, don't hesitate to slap me into the right direction, please.

On Mon, 05 Aug 2013 08:35:24 -0400
Jean-David Beyer <jeandavid8 at verizon.net> wrote:

> If somehow you trust the Linux kernel you are using, that is already a
> big assumption.
> 
> That would assure you that the Kernel source was used to compile the
> kernel. And if all was properly signed, and you have somehow obtained
> the fingerprint of the signing key in some reliable way, that would
> give high assurance.
> 
> But how about the compiler that was used. It could have been sabotaged
> too, to insert a back door into any code it compiled, or only code for
> files with names that exist in the compiler and a kernel, perhaps.
> 
> So not only need you trust the people who examined the source code for
> the kernel, you need to trust the people who support the kernel to
> have done the same thing for the compiler they use. And the compiler
> they used for compiling that compiler.
> 
> To really trust (or not trust), you have to take all that C-code for
> the first compiler and compile it by hand to binary (not assembly
> level). Then use that to make the assembler that has been similarly
> verified, then the C compiler you really want to use, and so on.

I can't do that myself yet, but I can roughly imagine a scripted way for
storing the signatures on some pool which could be checked in a
scripted way from command line or even a "trusted" gui in the future. I
even could live with a mechanism of cenralized archive for this like
the debian's packaging system.

> Do you use a web browser on the internet? If yes, then somone can
> target you with an exploit.

So looking a bit in the future I would say, if it is worth and really
would help to authenticate the trust of software, we [whoever sees
the need for it] could establish such an infrastructure in the next
years.

> Heh, but then Gentoo Linux users will look at you strangely if you say
> that you *don't* compile parts of your system. :-)
Surely they do because I don't compile all of system.

> > Do you know of signing mechanisms for developers to
> >  A have special keys for signing code changes
> >  B sign each others keys to approve they are knowledged enough to
> >  understand and check the code reliably.
> >  C sign a piece of software/patch/commit with it  
> 
> I don't see how this is different from a community building trust
> relationships for email.
I think it could set up on top of the debian web of trust or any
other developers's trust chain.
Currently for example debian maintainers undergo some social tests to
become DD once which does not mean that all their future  packages are
done well enough, to not allow any exploits (not talking about any
intended security holes). 

< http://lists.debian.org/debian-security/2013/08/msg00035.html
> For any who missed the scandal or need cribnotes:
> http://lwn.net/Articles/282038/
> http://www.links.org/?p=327
> http://www.links.org/?p=328

I had not time to go through all of this, but maybe some of you still
remember and can add some final thoughts.

Package checks and bug tracking are merely done on a trial and error
base. Although I know the security team takes big efforts to find such
vulnerabilites and to fix them in short time. (Which I am extremely
grateful for).
However, this has be shown to be insufficient and I wonder how a
structured process could look like to check packages before they wander
into a distro.

> I think a basic first step would be to disallow binary uploads, as
> ubuntu does.
Would this really help?

< http://lists.debian.org/debian-security/2013/08/msg00027.html
> Michael Stone:
> > On Sun, Aug 04, 2013 at 10:12:40AM +0200, Heimo Stranner wrote:
> >> I think the real issue is about if the malicious patch is not part
> >> of the source package
> > 
> > Why? It certainly makes your argument simpler if you arbitrarily
> > restrict the problem set, but it isn't obvious that it makes sense.
> > If I was going to backdoor something, I'd just make an
> > innocent-looking coding error that would enable a successful
> > exploit; I certainly wouldn't put in a commented section of code
> > that says "backdoor here". With sufficient effort it wouldn't be
> > hard to inject such a vulnerability that would go unnoticed for
> > years--and
> 
> > I'm not sure why
> > that's less of an issue than someone making a one-time build with a
> > malicious patch that is not part of the source package.
> 
> An innocent-looking coding error requires a malicious maintainer.
> 
> A malicious patch not part of the source code can be done by any
> adversary who compromised the build server. I think the latter is more
> simple, risk free and anonymous.
> 
> Getting rid of possibilities for intentional innocent-looking coding
> error is possible as well. First of all, how much security is the goal
> vs required effort? Is pragmatic security, as in "no random script
> kiddy can take down any Debian powered systems" sufficient or is it
> "we don't want all the three letter agencies around the globe being
> always able to remotely access any Debian system".
> 
> As far I know, only lower level programming languages such as
> assembler, C and C++ open up for sophisticated intentional
> innocent-looking coding errors, right? Bugs possibly leading to
> remote code execution are much more obvious to spot in higher level
> languages such as python?
> 
> If that case and more than pragmatic security is the goal, the use of
> lower level languages should be restricted to cases where other
> solutions aren't possible (bootloader etc.). And frozen. So that the
> code is 100% stable and vulnerability free after some time. It should
> be possible in theory if our machines get more performance over time?
> I think that would be quite painful to rewrite so many tools.
> 
> Are there any better solutions to the trusting trust issue? Or will
> the fight against backdoors be lost at some point?

> Checksums should be created on the .deb and the individual files. The
> advantage of deterministic builds would be, that these checksums would
> always be the same, no matter when and by whom the build is made as
> long as the source code isn't changed.
>
> Sure, deterministic builds are only the first step. Getting up a
> system to automatically to track changes in source code and to
> compare hash sums would be required as well.
> 
> I am afraid if deterministic builds can't solve all problems at once.
> Do you see no advantages at all? I am just interested to have in a
> couple of years still operating systems without any secretly built-in
> trojans because build servers got compromised with zero days.

> > I suppose that you could rig a compiler to compute signatures over
> > the sources it reads and incorporate these signatures into the
> > binary. Likewise the linker.  The whole toolchain would have to be
> > carefully considered and modified to suit.  I haven't heard of
> > anyone doing that.  (Someone will now point out that we would be
> > reposing even more trust in the toolchain, making its verification
> > more important.  Yes.)
> >
> > -- 
> > Mark H. Wood, Lead System Programmer   mwood at IUPUI.Edu
> > Machines should not be friendly.  Machines should be obedient.  
> 
> Here is one recent effort along this line of defense:

< https://bitcointalk.org/index.php?topic=83743.0
> Currently, before a new release of Bitcoin-Qt is published to
> SourceForge, it must be compiled by 3 different people who verify that
> they have produced the same exact binaries. This is done to protect
> against a variety of attack vectors: a single builder could include a
> trojan or backdoor into their binaries. No matter how much this person
> is trusted, their ability puts them at risk of being forced (eg, by
> gunpoint or legal action) to do so, or potential to do so accidentally
> (eg, if their build system is infected itself). Additionally, there is
> one person to impersonate or man-in-the-middle-attack, and the chance
> (5-10% in a person's lifetime, according to a quick Google) the person
> may begin to go insane. It also leaves open a question to the masses
> should that person die, of whether his successor is just as
> trustworthy.
> 
> However, right now, these thrice-verified builds are only possible for
> Linux and Windows using the Gitian framework. So far, Gavin has been
> personally responsible for the Mac OS X binaries, and he (and the
> community) incurs all the risks above as a result.

< http://gitian.org/howto.html
> To bootstrap a clean RubyGems installation, run:
> 
> % curl https://gitian.org/boot-gems | sh
>         
> This will:
> 
> Install RubyGems to ~/.gem
> Create ~/.profile-gem to be included in your shell startup script
> Install the Gitian gem
> The HighSecurity gem install policy will be activated, meaning that
> all gems must be signed with a trusted certificate. If you have to
> install a gem from another repository, you can turn off security
> temporarily with gem gitian --undo and turn it back on with gem
> gitian. Alternatively, you can download a gem and install it with gem
> install -P LowSecurity name.gem.
>
> USE WITH AN EXISTING RUBYGEMS INSTALLATION
> This is somewhat less secure, since it relies on your existing gem
> source (e.g. gemcutter) for obtaining the Gitian gem.
>
> % gem install gitian
> % gem gitian
>         
> This will display:
> 
> Please verify fingerprint for <info.deb at nginz.org> is
>  A9:24:34:B6:63:16:80:6A:06:9B:30:29:D0:EA:9C:0D:3D:86:A9:32

$ gem install gitian
Fetching: gitian-0.0.3.gem (100%)

========================================================================

           Thanks for installing Gitian! You can now run:

    gem gitian        use Gitian.org or another distribution as your
    main gem source

========================================================================

Successfully installed gitian-0.0.3
1 gem installed
Installing ri documentation for gitian-0.0.3...
Installing RDoc documentation for gitian-0.0.3...

$  gem gitian
Please verify fingerprint for <info.deb at nginz.org> is
 A9:24:34:B6:63:16:80:6A:06:9B:30:29:D0:EA:9C:0D:3D:86:A9:32
High security policy enabled.  You will get an 'unsigned gem' error if
you try to install a gem from a normal, non-signing gem repository.
Use 'gem gitian --undo' if you want to install an unsigned gem. Sources
in ~/.gemrc:
- https://gitian.org/rubygems/latest/
Gem defaults: --trust-policy HighSecurity

So from now in theory I can trust that all gems installed in the future
are signed with a trusted certificate. Unfortunately the files on 
https://gitian.org/rubygems/ are last touched in 2009 (same for
http://github.com/devrandom/gitian-tools ).

The gitian-builder for builds in a consolidated VM looks more current:
https://github.com/devrandom/gitian-builder
"This package can do a deterministic build of a package inside a VM"

So I have no conclusion but I would like to keep the discussion running
to step towards what seems impossible for now.

-- 
Kardan <kardan at riseup.net>
Encrypt your email: http://gnupg.org/documentation
Public GPG key 9D6108AE58C06558 at hkp://pool.sks-keyservers.net
fpr: F72F C4D9 6A52 16A1 E7C9  AE94 9D61 08AE 58C0 6558
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 620 bytes
Desc: not available
URL: </pipermail/attachments/20130807/df41fc9d/attachment-0001.sig>

More information about the Gnupg-users mailing list