Re: possible /dev/random compromise (misplaced trust in RDRAND / Padlock entropy sources)

2014-01-14 Thread Steven Chamberlain 
On 14/01/14 22:38, Robert Millan wrote:
> On 14/01/2014 22:25, Steven Chamberlain wrote:
>> Thankfully wheezy's 9.0 and 8.3 kernels had not enabled
>> either of those RNGs yet.
> 
> Are you sure? This is from 9.0:

Ahh, thanks for double-checking this.  You're right, kfreebsd-i386
kernels already supported the RNG in VIA Eden 32-bit CPUs... since 5.3.
 9.1 merely adds support for the RNG in Via Nano 64-bit CPUs.

Actually, it seems I have kfreebsd-i386 9.0 running on a VIA Eden CPU
right now with hardware RNG - should be handy for testing:

> CPU: VIA Eden Processor  500MHz (498.76-MHz 686-class CPU)
>   Origin = "CentaurHauls"  Id = 0x6d0  Family = 6  Model = d  Stepping = 0
>   
> Features=0xa7c9bbff
>   Features2=0x4181
>   AMD Features=0x10
>   VIA Padlock Features=0xffcc

There was no tunable to control use of this RNG until r240950 (which
went into the 9.2 release).  The changelog of when it was MFC'd doesn't
specifically mention that, but the original commit r240135 does:

http://svnweb.freebsd.org/base?view=revision&revision=240135
> Also add the tunables to disable hardware generator
> even if detected.

We could perhaps backport the tunable, then apply the patch for
EN-14:01.random as-is;  thus disabling the RNG by default but providing
a loader tunable to turn it back on.

And there was also this ironic snippet:

> From the Intel whitepapers and articles about Bull Mountain, it seems
> that we do not need to perform post-processing of RDRAND results, [...]
> Intel claims that sanitization is performed in hardware.

I've no reason to think VIA / Centaur Technology (Taiwanese owned) were
participating in the NSA's project BULLRUN, but it's nice that kfreebsd
10 is taking a cautious approach to all hardware RNGs now.

In any case, FreeBSD did an extra step of AES whitening on the output of
VIA's RNG - which was a nice precaution, especially in case of a
hardware defect - though it is still performed on-chip so can't be 100%
trusted.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52d5cf86.2060...@pyro.eu.org

Re: possible /dev/random compromise (misplaced trust in RDRAND / Padlock entropy sources)

2014-01-14 Thread Robert Millan 
On 14/01/2014 22:25, Steven Chamberlain wrote:
> Thankfully wheezy's 9.0 and 8.3 kernels had not enabled
> either of those RNGs yet.

Are you sure? This is from 9.0:

void
random_ident_hardware(struct random_systat *systat)
{

/* Set default to software */
*systat = random_yarrow;

/* Then go looking for hardware */
#if defined(__i386__) && !defined(PC98)
if (via_feature_rng & VIA_HAS_RNG) {
*systat = random_nehemiah;
}
#endif
}

-- 
Robert Millan


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52d5bc4b.90...@debian.org

Re: possible /dev/random compromise (misplaced trust in RDRAND / Padlock entropy sources)

2014-01-14 Thread Steven Chamberlain 
On 15/12/13 22:10, Robert Millan wrote:
> Perhaps we should just disable Via chipset from sys/dev/random/probe.c.
> Would this be a terrible loss for a Technology Preview release?

>From reading upstream's Errata Note[0], they have more or less done this
and disabled the hardware providers of /dev/{,u}random in stable/8 and
stable/9 by default.

[0]: http://security.freebsd.org/advisories/FreeBSD-EN-14:01.random.asc

Only the new code in kfreebsd/10 will be able to use the output of those
RNGs safely, probably feeding them into Yarrow as a potential extra
source of 'some' usable additional entropy.

VIA RNGs were enabled in 9.1 kernels, Intel Bull Mountain in 9.2, and
both in 8.4.  Thankfully wheezy's 9.0 and 8.3 kernels had not enabled
either of those RNGs yet.  Only kernels in jessie/sid (and before that,
experimental) have been potentially affected.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52d5ab5f.10...@pyro.eu.org

Re: possible /dev/random compromise (misplaced trust in RDRAND / Padlock entropy sources)

2013-12-15 Thread Henrique de Moraes Holschuh 
On Sun, 15 Dec 2013, Robert Millan wrote:
> > Backporting the fix to these kernels might be a good idea, probably best
> > routed through an stable update upload (and not a security upload).
> 
> This might be a bit complicated due to significant changes in internal
> APIs. I'm also unsure if the yarrow algorithms used in those versions
> are good enough for the task.
> 
> Perhaps we should just disable Via chipset from sys/dev/random/probe.c.
> Would this be a terrible loss for a Technology Preview release?

I don't think it would be a terrible loss.

OTOH, I wouldn't lose any sleep over a VIA PadLock HRNG driving /dev/random
in a tech preview release.

I am not sure VIA ever updated the design with CPRNGs, but the original
one-HRNG and the following two-HRNG designs are very audit-friendly.

Just make sure you give xstore (the new instruction used to read the VIA
PadLock HRNG) a full cacheline worth of buffer (which must also be
cacheline-aligned), due to CPU errata... you'll get memory corruption of
nearby data otherwise.  You also have to audit (or otherwise lock down) the
HRNG configuration, or assume it is operating in its worst mode while
post-processing.  The VIA PadLock RNG *is* a single MSR-write away from
being misconfigured.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131216004912.ga7...@khazad-dum.debian.net

Re: possible /dev/random compromise (misplaced trust in RDRAND / Padlock entropy sources)

2013-12-15 Thread Robert Millan 
On 14/12/2013 02:08, Henrique de Moraes Holschuh wrote:
>> kfreebsd 8.3 and 9.0 (wheezy):
>>  Sets Via chipset to serve /dev/random unconditionally whenever detected,
>>  but only on i386 (not amd64). Does not support Intel entropy source.
>>  (see sys/dev/random/probe.c)
> 
> Backporting the fix to these kernels might be a good idea, probably best
> routed through an stable update upload (and not a security upload).

This might be a bit complicated due to significant changes in internal
APIs. I'm also unsure if the yarrow algorithms used in those versions
are good enough for the task.

Perhaps we should just disable Via chipset from sys/dev/random/probe.c.
Would this be a terrible loss for a Technology Preview release?

>> kfreebsd 9.2 (jessie / sid):
>>  Sets Via or Intel chipset to serve /dev/random when detected,
>>  unless hw.nehemiah_rng_enable or hw.ivy_rng_enable are set to zero
>>  to disable them.
> 
> Remove, switch to kfreebsd 10.  Either that, or backport the fix from
> kfreebsd 10.

I tend to favour removal. Releasing with two kernels is a PITA.

What does everyone else think? Is someone interested in having 9.2 in
jessie?

-- 
Robert Millan


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52ae28d1.3040...@debian.org

Re: possible /dev/random compromise (misplaced trust in RDRAND / Padlock entropy sources)

2013-12-14 Thread Ben Hutchings 
On Sat, 2013-12-14 at 19:00 -0200, Henrique de Moraes Holschuh wrote:
> On Sat, 14 Dec 2013, Steven Chamberlain wrote:
> > On 14/12/13 01:08, Henrique de Moraes Holschuh wrote:
> > > Yeah, I think Linux went through similar blindness braindamage sometime 
> > > ago,
> > > but blind trust on rdrand has been fixed for a long time now, and it never
> > > trusted any of the other HRNGs (or used them for anything at all without a
> > > trip through "rng-tools" userspace until v3.12).
> > 
> > I seem to remember that Ted T'so's committed the fix for this only after
> > the release of Linux 3.2, so I assuemd wheezy's kernels might be still
> > affected?
> 
> I'd need to check it througoutly, but almost all important /dev/random
> changes in Linux were backported to all stable kernels, and thus eventually
> migrated into the Debian kernel (which is based on 3.2.y-stable plus lots of
> other backports).

If I understand rightly, in Linux 3.2 RDRAND (or other architectural
HWRNG) was used for get_random_int() and get_random_bytes() but not
for /dev/random or /dev/urandom.

Linux 3.2.27 (and other stable updates) inclued a large set of security
improvements for the RNG, primarily addressing lack of entropy at boot
(see ).  As part of this, an architectural HWRNG
will be used as a extra source of entropy for /dev/random and
/dev/urandom, but credited as providing only a fraction of a bit of
entropy.

get_random_bytes() was changed to not use an architectural HWRNG.
get_random_int() and get_random_bytes_arch() will use it and it is
documented that they are not suitable for cryptographic purposes.

Ben.

-- 
Ben Hutchings
Knowledge is power.  France is bacon.


signature.asc
Description: This is a digitally signed message part

Re: possible /dev/random compromise (misplaced trust in RDRAND / Padlock entropy sources)

2013-12-14 Thread Henrique de Moraes Holschuh 
On Sat, 14 Dec 2013, Steven Chamberlain wrote:
> On 14/12/13 01:08, Henrique de Moraes Holschuh wrote:
> > Yeah, I think Linux went through similar blindness braindamage sometime ago,
> > but blind trust on rdrand has been fixed for a long time now, and it never
> > trusted any of the other HRNGs (or used them for anything at all without a
> > trip through "rng-tools" userspace until v3.12).
> 
> I seem to remember that Ted T'so's committed the fix for this only after
> the release of Linux 3.2, so I assuemd wheezy's kernels might be still
> affected?

I'd need to check it througoutly, but almost all important /dev/random
changes in Linux were backported to all stable kernels, and thus eventually
migrated into the Debian kernel (which is based on 3.2.y-stable plus lots of
other backports).

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131214210047.ga29...@khazad-dum.debian.net

Re: possible /dev/random compromise (misplaced trust in RDRAND / Padlock entropy sources)

2013-12-14 Thread Steven Chamberlain 
On 14/12/13 11:18, Cyril Brulebois wrote:
> If you're talking about this:
> | commit c2557a303ab6712bb6e09447df828c557c710ac9
> | Author: Theodore Ts'o 
> | Date:   Thu Jul 5 10:35:23 2012 -0400
> | 
> | random: add new get_random_bytes_arch() function
> | […]
> 
> it was backported into 3.2.y, that would be 
> 7f5d5266f8a1f7f54707c15e028f220d329726f4
> also known as v3.2.27~51.

Ah yes, excellent.  Thank you.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org



signature.asc
Description: OpenPGP digital signature

Re: possible /dev/random compromise (misplaced trust in RDRAND / Padlock entropy sources)

2013-12-14 Thread Cyril Brulebois 
Steven Chamberlain  (2013-12-14):
> On 14/12/13 01:08, Henrique de Moraes Holschuh wrote:
> > Yeah, I think Linux went through similar blindness braindamage sometime ago,
> > but blind trust on rdrand has been fixed for a long time now, and it never
> > trusted any of the other HRNGs (or used them for anything at all without a
> > trip through "rng-tools" userspace until v3.12).
> 
> I seem to remember that Ted T'so's committed the fix for this only after
> the release of Linux 3.2, so I assuemd wheezy's kernels might be still
> affected?

If you're talking about this:
| commit c2557a303ab6712bb6e09447df828c557c710ac9
| Author: Theodore Ts'o 
| Date:   Thu Jul 5 10:35:23 2012 -0400
| 
| random: add new get_random_bytes_arch() function
| […]

it was backported into 3.2.y, that would be 
7f5d5266f8a1f7f54707c15e028f220d329726f4
also known as v3.2.27~51.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: possible /dev/random compromise (misplaced trust in RDRAND / Padlock entropy sources)

2013-12-14 Thread Steven Chamberlain 
Hi,

On 14/12/13 01:08, Henrique de Moraes Holschuh wrote:
> Yeah, I think Linux went through similar blindness braindamage sometime ago,
> but blind trust on rdrand has been fixed for a long time now, and it never
> trusted any of the other HRNGs (or used them for anything at all without a
> trip through "rng-tools" userspace until v3.12).

I seem to remember that Ted T'so's committed the fix for this only after
the release of Linux 3.2, so I assuemd wheezy's kernels might be still
affected?

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52ac1eb5.7020...@pyro.eu.org

Re: possible /dev/random compromise (misplaced trust in RDRAND / Padlock entropy sources)

2013-12-13 Thread Henrique de Moraes Holschuh 
On Sat, 14 Dec 2013, Robert Millan wrote:
> "we are going to backtrack and remove RDRAND and Padlock backends and feed
> them into Yarrow instead of delivering their output directly to /dev/random.

Yeah, I think Linux went through similar blindness braindamage sometime ago,
but blind trust on rdrand has been fixed for a long time now, and it never
trusted any of the other HRNGs (or used them for anything at all without a
trip through "rng-tools" userspace until v3.12).

> Advice from Security Team would be appreciated in order to determine which
> action needs to be taken in Debian.

IMO, Debian kernels ought to never blindly trust RDRAND, or any other HRNG,
for anything related to /dev/random.

Note that the kernel can trust such in-cpu, high-bandwidth/low-latency HRNGs
for other uses that are not related to key material (such as to implement
ASLR).

> kfreebsd 8.3 and 9.0 (wheezy):
>   Sets Via chipset to serve /dev/random unconditionally whenever detected,
>   but only on i386 (not amd64). Does not support Intel entropy source.
>   (see sys/dev/random/probe.c)

Backporting the fix to these kernels might be a good idea, probably best
routed through an stable update upload (and not a security upload).

> kfreebsd 9.2 (jessie / sid):
>   Sets Via or Intel chipset to serve /dev/random when detected,
>   unless hw.nehemiah_rng_enable or hw.ivy_rng_enable are set to zero
>   to disable them.

Remove, switch to kfreebsd 10.  Either that, or backport the fix from
kfreebsd 10.

> kfreebsd 10~ (sid):
>   All versions in Debian already have the fixed code, which replaces
>   random_adaptor_register() with live_entropy_source_register(), thereby
>   registering Via and Intel chips as "entropy sources" to be post
>   processed by Yarrow, rather than directly as "random adaptors".

Quite acceptable, as it means we'd have the same policy across Linux and
kFreeBSD.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131214010823.gc26...@khazad-dum.debian.net