[Bloat] [Cerowrt-devel] wired article about bleed and bloat and underfunded critical infrastructure

[Dave Taht]

On Fri, Apr 11, 2014 at 12:43 PM,  <dpreed at reed.com> wrote:
> I'm afraid it's not *just* underfunded.   I reviewed the details of the code
> involved and the fixes, and my conclusion is that even programmers of
> security software have not learned how to think about design, testing, etc.
> Especially the continuing use of C in a large shared process address space
> for writing protocols that are by definition in the "security kernel"
> (according to the original definition) of applications on which the public
> depends.
>
>
>
> Ever since I was part of the Multics Security Project (which was part of the
> effort that produced the Orange Book
> http://csrc.nist.gov/publications/history/dod85.pdf)

Which I incidentally have read... and fail to see how it applies well
to networked systems.

> in the 80's, we've
> known that security-based code should not be exposed to user code and vice
> versa.  Yet the SSL libraries are linked in, in userspace, with the
> application code.

I note that I am glad that they are mostly dynamically linked in -
something that wasn't the case for some other crypto libs - because
finding applications
that linked statically would be even more difficult.

And I have seen some reports of people using heavily patched openssl
doing smarter things with memory allocation - why weren't those patches
pushed back into openssl?

Well, because they were held private and not publicly reviewed... and
don't appear to actually work, according to this:

http://lekkertech.net/akamai.txt

> Also, upgrades/changes to protocols related to security (which always should
> have been in place on every end-to-end connection) should be reviewed *both
> at the protocol design level* and also at the *implementation level* because
> change creates risk.  They should not be adopted blindly without serious
> examination and pen-testing, yet this change just was casually thrown in in
> a patch release.

Yes, change creates risk. Change also breeds change. Without change
there would be no progress.

Should there be an "office of critical infrastructure" or an
underwriters labratory examining and blessing each piece of software
that runs as root or handles money? Should some governmental or
intergovernmental group be putting a floor under (or a roof over) the
people working on code deemed as critical infrastructure?

heartbleed was not detected by a coverity scan either.

> I suspect that even if it were well funded, the folks who deploy the
> technology would be slapdash at best.

I agree. Recently I was asked to come up with an "phone-home inside
your business embedded device architecture" that would scale to
millions of users.

I don't want the responsibility, nor do I think any but hundreds of
people working together could come up with something that would let me
sleep well at night - yet the market demand is there for something,
anything, that even barely works.

If I don't do the work, someone less qualified will.


> Remember the Y2K issue

I do. I also remember the response to it.

http://www.taht.net/~mtaht/uncle_bills_helicopter.html

The response to heartbleed has been incredibly heartening as to the
swiftness of repair - something that could not have happened in
anything other than the open source world. I have friends, however,
that just went days without sleep, fixing it.

I've outlined my major concerns with TLS across our critical
infrastructure going forward on my g+.

> and the cost of
> lazy thinking about dates. (I feel a little superior because in 1968 Multics
> standardized on a 72-bit hardware microsecond-resolution hardware clock
> because the designers actually thought about long-lived systems (actually

I agree that was far-thinking. I too worry about Y2036 and Y2038, and
do my best to make sure those aren't problems.

it seems likely some software will last even longer than that.

> only 56 bits of the original clock worked, but the hardware was not expected
> to last until the remaining bits could be added)).

Multics died. It would not have scaled to the internet. And crypto
development and public deployment COULD have gone more hand in hand if
it weren't basically illegal until 1994, and maybe before then, some
reasonable security could have been embedded deep into more protocols.

It would have been nice to have had a secured X11 protocol, or
kerberos made globally deployable, or things like mosh, in the 80s. In
terms of more recent events, I happen to have liked HIP.

We don't know how to build secured network systems to this day, that
can survive an exposure to hundreds of millions of potential
attackers.
>
>
> The open source movement, unfortunately, made a monoculture of the SSL
> source code, so it's much more dangerous and the vulnerable attack surface
> of deployments is enormous.

No it didn't. Alternatives to openssl exist - gnutls, cyassl, and
polarssl are also open source. Libraries that merely implement
primitives well like nettle, gmp, and libsodium - all developed later
- also exist.

I am GLAD we don't have a monoculture in crypto.

What happened was mostly inertia from openssl being the first even
semi-legal library for crypto operations and huge demand for the
functionality backed up with too little understanding of the risks.


>
>
>
> Rant off.  The summary is that good engineering is not applied where it must
> be for the public interest.  That remains true even if the NSA actually
> snuck this code into the SSL implementation.
>
>
>
> On Friday, April 11, 2014 2:22pm, "Dave Taht" <dave.taht at gmail.com> said:
>
>> http://www.wired.com/2014/04/heartbleedslesson/
>>
>> And Dan Kaminisky writes about "Code in the Age of Cholera"
>>
>> http://dankaminsky.com/2014/04/10/heartbleed/
>>
>>
>>
>> --
>> Dave Täht
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel at lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>



-- 
Dave Täht

NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article