[sf-lug] interesting news/info or not?

[Rick Moen]

Quoting Frantisek Apfelbeck (algoldor at yahoo.com):

> Hi to all,

All says 'Greetings!'

> I've just read this post about Julian Assange's recent speech
> http://igurublog.wordpress.com/2014/04/08/julian-assange-debian-is-owned-by-the-nsa/
> where he is claiming several for me quite disturbing things which I
> did not realized really before.
> 
> Could you comment at least on some issues mentioned?

A careful assessment would involve listening to (watching, whatever)
Assange's 36 minute speech w/Q&A, and take careful notes.  I have not
done so because I haven't had anything like the time.

I'm sorry about that, because I do think Assange is a serious person,
and one of pivotal importance in recent public affairs.  FWIW, he has
also struck me as more than a bit unhinged -- though both that and his
personal paranoia have substantial justification.

One of the thing that the pseudonymous (and also apparently a bit
unhinged) person yclept 'IgnorantGuru' says Assange alleged is that the
Debian developer's erroneous patch to an OpenSSL random number generator
code was deliberate sabotage.  'IgnorantGuru' voices his opinion on the
matter, too, saying 'clearly sabotaged - a known fact'.

This is something I do know something about.  It's a rubbish bit of
melodrama conspiracy-think.

Here's how I put it on a different mailing list some months ago:

   > Let's not forget CVE-2008-0166, a backdoor in Debian/Ubuntu that
   > remained undiscovered for 20 months. Fun slideware:
   > https://trailofbits.files.wordpress.com/2008/07/hope-08-openssl.pdf

   Kurt Roeckx's good-faith effort to fix OpenSSL PNG spaghetti code[1]
   was not 'a trapdoor', but rather an unsuccessful effort to polish the
   turd that is OpenSSL.

   > I found this message interesting:
   > http://www.mail-archive.com/freebsd-security@freebsd.org/msg04439.html

   Well, yeah.  That whole thread is spot-on.

   [1] http://www.peereboom.us/assl/assl/html/openssl.html


Linux Weekly News had a good analysis at the time (May 2008):
http://lwn.net/Articles/282038/  Essentially:  In an attempt to
fix a real code problem (problems revealed by Valgrind) in some
extremely badly written, buggy and confusing OpenSS codeL, Roeckx
_asked_ the OpenSSL developers whether it would be a good idea to
comment out two lines of code he thought were responsible for the
problem -- and one of the original core OpenSSL developers, Ulf Moeller,
gave Roeckx a lukewarm OK:  'If it helps with debugging, I'm in favor of
removing them.'

Unfortunately for Roeckx and for the state of Debian's OpenSSL package
in 2008, it turned out that these two lines were related to an
undocumented routine where OpenSSL was _using uninitialised memory_ 
for the RNG function.  That's a pretty crazy thing to do in an RNG,
and especially to do so with no explanation whatsoever.  The real-world 
effect of Roeckx's patch was to cripple RNG randomness, making
OpenSSL-generated crypto keys easier to predict and thus break.

Let me recap the key point for a moment:  RNG seeding code is vital to
crypto.  OpenSSL's implementation of that seeding is irresponsibly,
ridiculously wacky -- and not explained.  


Roeckx's approach was quite reasonable in context, _and_ far from doing
anything furtively, he actually asked the OpenSSL devs whether he should
apply his proposed patch.  And one of them said fine, do it.

Ben Laurie of the OpenSSL team angrily attempted to make all of the
resulting problems Roeckx's patch caused be his fault, saying Roeckx
hadn't asked on the right mailing list (but the OpenSSL support Web page
claims it is), and that he should have immediately submitted his patch
upstream to OpenSSL itself rather than just to the Debian package.
And Laurie has no comment on the OpenSSL code in question being
extremely misleading and devoid of comments and documentation on matters
that are nonstandard and peculiar in the code.

Yes, it would have been better of Roeckx had submitted an upstream
patch.  One hopes that he and also the ~1000 other Debian devs make a
point of helping upstream as much as possible.  However, being slow to do
so, or failing to do so, is pretty common and not a reason to accuse a
package maintainer of sabotage.

Meanwhile, I'm betting that the truly abysmal code in the RNG is no
better, and has no documentation of its peculiaries -- other than all
the online namecalling hurled at Roeckx.


'But Rick', you might ask, 'what about IgnorantGuru's (and Assange's) 
other laundry lists of conspiracy accusations?'  I'll be nice and say
that I just don't have time to try to chase down a lot of melodramatic
conspiracy claims.

One of IgnorantGuru's claims is about 'Red Hat’s deep control of Linux'.
Let's talk about that:  There is a huge presence by Red Hat employees 
in the committer logs of many open-source projects -- lots of redhat.com
commits.  Unlike, say, Canonical, Ltd., Red Hat, Inc. is a huge
underwriter of the people who maintain our key projects, from the kernel
on up.

I know a bunch of those engineers, many of those being ones I worked
with at VA Linux Systems, Inc.  They're not spooks; they're fairly
independent-minded geeks who would not hesitate to blab here and there
and everywhere about any orders, given to them or others, to weaken or
limit security in any of the codebases.

IgnorantGuru's Red Hat smoking gun:  Red Hat didn't incorporate a
non-mainline kernel patch to add Loop AES (which IgnorantGuru calls
AES-loop) to Red Hat's vendor kernel.  Loop-AES is code that permits you
to mount a 'loopback device' as an encrypted filesystem.  Curiously, 
IgnorantGuru does _not_ accuse Linus and the other kernel.org coders of
the same fault, even though they never accepted this kernel patch,
either.  (Thus, it remains a non-mainline patch.)

Red Hat's engineer Arjan van de Ven declined the patch in 2004 with the
comment 'Actually, this code has been superceded by the dm-crypt, the
crypto device mapper code, which we do include. There's no point putting
loop-aes in now.'

Those of us who shave with Occam's Razor might consider the merits of
what van de Ven was saying, and it's not difficult to figure out the
unstated, non-melodramatic reasons behind his reason:  Loop-AES would be
a maintenance burden on Red Hat because it's out-of-tree code.  dm-crypt
is already present as a de-facto standard that already integrates with
device-mapper without any remedial backfilling of support code.  And
people who nonetheless want Loop-AES anyway are perfectly welcome to
apply the patch to Red Hat's (or kernel.org's) kernel source code and
compile it, which isn't actually difficult.

Some of us call that the most parsimonious explanation of something not
very dramatic and not at all sinister.  But maybe we're all on the 
$THREE_LETTER_AGENCY payroll and are trying to fool you.  Adjust your
paranoia to suit your local needs.