[gentoo-hardened] Running short of entropy...

[gentoo-hardened] Running short of entropy...

[Ed W]

Hi, running an up to date hardened+grsec+pax on x86_64bit system (quad 
core2) and I think I may be running short of entropy, presumed due to SSP?

Essentially I have two or three digit numbers from 
/proc/sys/kernel/random/entropy_avail
The grsec "larger entropy pools" option is enabled

The LFS notes suggest that erandom is a possible solution.  Does anyone 
have any notes on dropping SSP into a lower quality/faster random number 
source?

I don't have physical access to all machines, so any interesting cheap 
random number generator dongles would be interesting to know about, but 
will not be a full solution in this case. If I'm missing some obvious 
option which is available on recent Intel/AMD hardware which might give 
me larger amounts of entropy then please shout?

Thanks for any advice

Ed W

Re: [gentoo-hardened] Running short of entropy...

[Natanael Copa]

On Wed, Mar 3, 2010 at 5:14 PM, Ed W <lists@wildgooses.com> wrote:

> I don't have physical access to all machines, so any interesting cheap
> random number generator dongles would be interesting to know about, but will
> not be a full solution in this case. If I'm missing some obvious option
> which is available on recent Intel/AMD hardware which might give me larger
> amounts of entropy then please shout?

media-sound/audio-entropyd?

-- 
Natanael Copa

Re: [gentoo-hardened] Running short of entropy...

[Ed W]

On 03/03/2010 17:35, Natanael Copa wrote:
> On Wed, Mar 3, 2010 at 5:14 PM, Ed W<lists@wildgooses.com>  wrote:
>
>    
>> I don't have physical access to all machines, so any interesting cheap
>> random number generator dongles would be interesting to know about, but will
>> not be a full solution in this case. If I'm missing some obvious option
>> which is available on recent Intel/AMD hardware which might give me larger
>> amounts of entropy then please shout?
>>      
> media-sound/audio-entropyd?
>
>    

Thanks for the idea - the server is a rackmount thing rented from a 
hosting company and I don't think it has any soundcard onboard...

I believe that the kernel doesn't use the network interrupt for 
randomness, only keyboard, mouse and HD.  This isn't a great situation 
for a headless, mouseless webserver which tries as hard as possible not 
to touch the disk...

I ordered an "Entropy Key" from here: http://www.entropykey.co.uk/

This will help for the office server, but it doesn't really sort out my 
rented racks (no, don't really want some crazy solution involving ssh 
piping the data to it...)

Would be very grateful for any other ideas here. I think the solution is 
likely to use a lower quality rng source for the SSP protection rather 
than generating more entropy - I'm not really see that a super high 
quality rng source is really needed for SSP?  Possibly a local attacker 
can write code which flogs the rng until they figure out the params, 
then use it as part of an SSP attack, however, its low on my list of 
fears...

I can see that glibc previously used to use erandom, but this patch was 
dropped - any reason?

Cheers

Ed W

Re: [gentoo-hardened] Running short of entropy...

[Brian Kroth]

[-- Attachment #1: Type: text/plain, Size: 2669 bytes --]

Ed W <lists@wildgooses.com> 2010-03-03 18:41:
> On 03/03/2010 17:35, Natanael Copa wrote:
>> On Wed, Mar 3, 2010 at 5:14 PM, Ed W<lists@wildgooses.com>  wrote:
>>
>>    
>>> I don't have physical access to all machines, so any interesting cheap
>>> random number generator dongles would be interesting to know about, but will
>>> not be a full solution in this case. If I'm missing some obvious option
>>> which is available on recent Intel/AMD hardware which might give me larger
>>> amounts of entropy then please shout?
>>>      
>> media-sound/audio-entropyd?
>>
>>    
>
> Thanks for the idea - the server is a rackmount thing rented from a  
> hosting company and I don't think it has any soundcard onboard...
>
> I believe that the kernel doesn't use the network interrupt for  
> randomness, only keyboard, mouse and HD.  This isn't a great situation  
> for a headless, mouseless webserver which tries as hard as possible not  
> to touch the disk...
>
> I ordered an "Entropy Key" from here: http://www.entropykey.co.uk/
>
> This will help for the office server, but it doesn't really sort out my  
> rented racks (no, don't really want some crazy solution involving ssh  
> piping the data to it...)
>
> Would be very grateful for any other ideas here. I think the solution is  
> likely to use a lower quality rng source for the SSP protection rather  
> than generating more entropy - I'm not really see that a super high  
> quality rng source is really needed for SSP?  Possibly a local attacker  
> can write code which flogs the rng until they figure out the params,  
> then use it as part of an SSP attack, however, its low on my list of  
> fears...
>
> I can see that glibc previously used to use erandom, but this patch was  
> dropped - any reason?
>
> Cheers
>
> Ed W

Interesting subject.

Here's [1] another technique I found to make use of the rng in the TPM if it's
available.  Seems to be working fairly well in my tests so far [3], though I
think I'd prefer an entropy key as well.  From some other reading [2] it
seems that the virtio-rng modules (for use with qemu/kvm based guests)
can make use of a host side /dev/hw_random device which I believe the
entropy key provides.  The TPM currently does not, though may in the
future.

Cheers,
Brian

[1] http://www.outflux.net/blog/archives/2010/02/08/rng-tools-with-tpm/
[2] http://lwn.net/Articles/283103/
[3] I was able to enable it in the BIOS using the IPMI SOL, so hopefully
you won't need physical access.  Not doing anything like TrustedGrub
yet.  To be honest, I don't really see the point.  Feel free to
enlighten me.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-hardened] Running short of entropy...

[Joseph C. Lininger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

> I think I may be running short of entropy, presumed due to SSP?
> Essentially I have two or three digit numbers from /proc/sys/kernel/random/entropy_avail

Try timer_entropyd. It's written by the same person who wrote
audio_entropyd and video_entropyd. The up side is you don't need any
special hardware and it will jump your available entropy up by quite a
bit. Not as good as a true hardware generator most likely, but probably
perfectly fine for your purposes.

http://www.vanheusden.com/te/

It's not available in portage, though I've been looking at writing an
ebuild for it. I am not a cryptographer, and can not speak as to the
quality of the random data. I have run FIPS tests on /dev/random with it
in use, however, and in the tests I ran no blocks of random data failed
the tests.
- -- 
Yes means no and no means yes. Delete all files [Y]?
Joseph C. Lininger, <jbahm@pcdesk.net>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iQEcBAEBCAAGBQJLlI/RAAoJEMh8jNraUiwqQLIH/izshiIa6U63AI6jmUXvd9Iq
fEhWJ3s5AvkdfxYZZ10LznqjOhmOQhtllrgFX+k/2fvJ869lJ3d9oGB1LVW3/ZyD
ACXC6XFfyFVJRTu1EE9BsF26p+Kow5pvc0m1Bmp9hep8KjHipwohSX/fgCQ45XET
3fmfZ6uJrvmmJMpy1b6SsbCUlXwvMmoz8Gx5BArbDDiaIra7v5d6iXg53TtCI5Y+
oONv1XqpqSYR07hhRrXIQ44h8iVyJAVjgtGlGx6H3LA4NmWzO/eix/9aS3xbPemU
6qKf1xyyTnTZoDOLhBqXVhQD1gk0qZWXuCjb5aA/MdSyNXt4AsGPJVQaOc2Fv+E=
=VxZe
-----END PGP SIGNATURE-----

Re: [gentoo-hardened] Running short of entropy...

[Ed W]

On 08/03/2010 05:49, Joseph C. Lininger wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
>    
>> I think I may be running short of entropy, presumed due to SSP?
>> Essentially I have two or three digit numbers from /proc/sys/kernel/random/entropy_avail
>>      
> Try timer_entropyd. It's written by the same person who wrote
> audio_entropyd and video_entropyd. The up side is you don't need any
> special hardware and it will jump your available entropy up by quite a
> bit. Not as good as a true hardware generator most likely, but probably
> perfectly fine for your purposes.
>
> http://www.vanheusden.com/te/
>
> It's not available in portage, though I've been looking at writing an
> ebuild for it.
>    

Thanks for the suggestion - I had spotted it, but skipped over it 
temporarily since there was no ebuild.

I also tried clrngd that someone suggested offlist - this doesn't seem 
to be generating entropy fast enough and it takes over 60 seconds of 
100% CPU to generate what it does generate.

I'm fairly sure that the answer here is to switch to using a lower 
quality rng for the canary - this leaves the high quality rng for all 
important crypto related stuff where we really shouldn't be compromising 
on quality.  I guess some patch to use network packets to seed the pool 
with randomness would also be useful, btu that's way beyond what I'm 
going to offer a patch for in the near future...

I'm going to look through the older glibc patches to see how it used to 
be done (using /dev/erandom), but any one with more experience on why it 
was *removed* from current glibc would be grateful to hear your thoughts?

Thanks

Ed W

Re: [gentoo-hardened] Running short of entropy...

[Joseph C. Lininger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

> Thanks for the suggestion - I had spotted it, but skipped over it temporarily since
> there was no ebuild.
> I also tried clrngd that someone suggested offlist - this doesn't seem to be generating
> entropy fast enough and it takes over 60 seconds of 100% CPU to generate what it
> does generate.

timer_entropyd doesn't suffer from that particular problem. It will add
a fair amount of randomness to your system and it will do it on a
regular bases. It's not too hard on your CPU either.

> I'm fairly sure that the answer here is to switch to using a lower quality rng for
> the canary - this leaves the high quality rng for all important crypto related stuff
> where we really shouldn't be compromising on quality.

I'm not sure exactly how ssp is implemented in a nuts and bolts sort of
way. However, I would say lowering the quality of the random data used
for the canary would be a bad idea. It could allow someone to more
easily compromise a system protected by ssp. A better aproach would be
to find a way to add more high quality random data to the pool if that's
what's causing the problem if at all possible.
- -- 
Yes means no and no means yes. Delete all files [Y]?
Joseph C. Lininger, <jbahm@pcdesk.net>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iQEcBAEBCAAGBQJLlU0yAAoJEMh8jNraUiwqgLcH/0nWOTlsZLJcQ9r+i9El1B+7
HzmedRPmQ00aPkAZz6d9GldEH3ydxWxZMOvf7Wj4GVE3R99E6Ur/wT2lORx+YgBg
tbi2wHh9pAXIJ/qhYuNtL4C38VwGimBLWuyHaUP4zQB0mNQ4nsC798s05FaPdwM7
TRbj8c15kQtWqUd2cpw4CnLJGMxotwj67YpofYmVStpnt3Nl9ppOCZXP3AFIADi9
r9kUW+rjBFFtYlt2eR077RheNtwqTAyx8fcAhWhzMaFSEgbd/r8b7RdVwMJMYo+/
ysD5XMkf+r7QftcNHWq3slxVBTbz/9dkDdrYjVEmfDhZtDgz1JOgkPcxeVvU6I4=
=M6IN
-----END PGP SIGNATURE-----

Re: [gentoo-hardened] Running short of entropy...

[Ed W]

> I'm not sure exactly how ssp is implemented in a nuts and bolts sort of
> way. However, I would say lowering the quality of the random data used
> for the canary would be a bad idea. It could allow someone to more
> easily compromise a system protected by ssp.


There's no doubt that it lowers security, but I think even if you just 
picked a fixed canary value per system (say 42) then it already means 
that most buffer overflow attacks still fail..

Agreed that someone specifically targeting you will get in, but I'm far 
more worried about the general class of attacks... SSP is just one more 
layer of security, not the only layer

Cheers

Ed W

Re: [gentoo-hardened] Running short of entropy...

[Michael Orlitzky]

Ed W wrote:
> On 08/03/2010 05:49, Joseph C. Lininger wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>>
>>   
>>> I think I may be running short of entropy, presumed due to SSP?
>>> Essentially I have two or three digit numbers from 
>>> /proc/sys/kernel/random/entropy_avail
>>>      
>> Try timer_entropyd. It's written by the same person who wrote
>> audio_entropyd and video_entropyd. The up side is you don't need any
>> special hardware and it will jump your available entropy up by quite a
>> bit. Not as good as a true hardware generator most likely, but probably
>> perfectly fine for your purposes.
>>
>> http://www.vanheusden.com/te/
>>
>> It's not available in portage, though I've been looking at writing an
>> ebuild for it.
>>    
> 
> Thanks for the suggestion - I had spotted it, but skipped over it 
> temporarily since there was no ebuild.

I posted one to Bugzilla if you don't mind maintaining your own 
overlays. Once it gets re-assigned and I've had enough coffee to 
understand their FAQ, I might try to get it committed to sunrise.

http://bugs.gentoo.org/show_bug.cgi?id=308599

Re: [gentoo-hardened] Running short of entropy...

[Roger Light]

(I sent this with my non-list address first by mistake, so apologies
if it comes through twice).

On Mon, Mar 8, 2010 at 8:48 AM, Ed W <lists@wildgooses.com> wrote:

>  I guess some patch to use network packets to seed the pool with randomness
> would also be useful, btu that's way beyond what I'm going to offer a patch
> for in the near future...

About two years ago I emailed the maintainer of the via_rhine network
driver, Roger Luethi, asking whether adding IRQF_SAMPLE_RANDOM to the
flags in its call to request_irq()  would be appropriate or not. His
reply included:

"If you check the other network drivers, most don't do that. IIRC the
argument was that interrupts in network drivers can to some extent be
controlled from the outside, so they should not be used as a source for
randomness."

If you want to try it, it's an extremely simple change to your network
driver, along the lines of:

-        rc = request_irq(rp->pdev->irq, &rhine_interrupt,
IRQF_SHARED, dev->name,
+       rc = request_irq(rp->pdev->irq, &rhine_interrupt, IRQF_SHARED
| IRQF_SAMPLE_RANDOM, dev->name,

He also suggested bringing it up on the lkml if I wanted, after
checking the archives. I did neither, but it's there as an option for
you.

Cheers,

Roger

Re: [gentoo-hardened] Running short of entropy...

[Brian Kroth]

[-- Attachment #1: Type: text/plain, Size: 2299 bytes --]

Roger Light <rogerlight@gmail.com> 2010-03-09 09:09:
> (I sent this with my non-list address first by mistake, so apologies
> if it comes through twice).
> 
> On Mon, Mar 8, 2010 at 8:48 AM, Ed W <lists@wildgooses.com> wrote:
> 
> >  I guess some patch to use network packets to seed the pool with randomness
> > would also be useful, btu that's way beyond what I'm going to offer a patch
> > for in the near future...
> 
> About two years ago I emailed the maintainer of the via_rhine network
> driver, Roger Luethi, asking whether adding IRQF_SAMPLE_RANDOM to the
> flags in its call to request_irq()  would be appropriate or not. His
> reply included:
> 
> "If you check the other network drivers, most don't do that. IIRC the
> argument was that interrupts in network drivers can to some extent be
> controlled from the outside, so they should not be used as a source for
> randomness."
> 
> If you want to try it, it's an extremely simple change to your network
> driver, along the lines of:
> 
> -        rc = request_irq(rp->pdev->irq, &rhine_interrupt,
> IRQF_SHARED, dev->name,
> +       rc = request_irq(rp->pdev->irq, &rhine_interrupt, IRQF_SHARED
> | IRQF_SAMPLE_RANDOM, dev->name,
> 
> He also suggested bringing it up on the lkml if I wanted, after
> checking the archives. I did neither, but it's there as an option for
> you.
> 
> Cheers,
> 
> Roger

I read a couple of interesting threads regarding some arguments for and
against that yesterday.

My basic reading is that 

- IRF_SAMPLE_RANDOM is due to be replaced by some other interface that's
  common to all input devices.

- There's a general feeling that gathering entropy from a network device
  can be remotely influenced and is therefore probably not ideal.  In
  theory entropy can be obtained fairly well from other sources, like
  the various egds mentioned already on this thread, or just by doing
  hashes over some other special devices that that kernel already
  provides.

Here's some links:
http://lkml.indiana.edu/hypermail/linux/kernel/0805.1/2091.html
http://linux.derkeiler.com/Mailing-Lists/Kernel/2006-05/msg01294.html
http://thread.gmane.org/gmane.linux.kernel/680723
http://kerneltrap.org/mailarchive/linux-netdev/2009/4/6/5419494

Cheers,
Brian

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-hardened] Running short of entropy...

[Ed W]

On 09/03/2010 14:49, Brian Kroth wrote:
> I read a couple of interesting threads regarding some arguments for and
> against that yesterday.
>
> My basic reading is that
>
> - IRF_SAMPLE_RANDOM is due to be replaced by some other interface that's
>    common to all input devices.
>
> - There's a general feeling that gathering entropy from a network device
>    can be remotely influenced and is therefore probably not ideal.  In
>    theory entropy can be obtained fairly well from other sources, like
>    the various egds mentioned already on this thread, or just by doing
>    hashes over some other special devices that that kernel already
>    provides.
>    

Hmm, that's interesting reading - thanks for the links

I'm not a cryto guy, so by definition I'm wrong, BUT, ignoring sources 
of entropy just seems wrong...

The argument seems to be that:

- You can observe network packets to a high accuracy under *some* 
circumstances
- You can also observe other sources of entropy under some circumstances
- Therefore under a fairly constrained set of circumstances it would be 
possible to feed only known entropy into the /dev/random pool
- Under these circumstances it might be possible to figure out the 
output of the rng

The counter argument is:
- Instead my entropy pool just ran dry
- This means that all important crypto algorithms are using /dev/urandom 
anyway
- Once the entropy pool runs dry we are purely down to the rng 
algorithms anyway - so the quality of our rng is severely reduced...

Seems like you are stuffed either way...

The two big problems seem to be:
- Using the same source for both high quality cryto needs (small number 
of high quality rng needed) and non crypto needs (eg SSP)
- Lack of a unified feed for entropy which can take "poor" sources of 
entropy and still use them by blending them with higher quality sources 
(feeding in a known source of entropy from an attacker should not be a 
problem assuming a secure hash function and enough unknown entropy to 
make a bruteforce attack impractical)


hmm...


Ed W

Re: [gentoo-hardened] Running short of entropy...

[Ed W]

On 09/03/2010 08:16, Michael Orlitzky wrote:
> I posted one to Bugzilla if you don't mind maintaining your own 
> overlays. Once it gets re-assigned and I've had enough coffee to 
> understand their FAQ, I might try to get it committed to sunrise.
>
> http://bugs.gentoo.org/show_bug.cgi?id=308599

Wow - that thing is filling the entropy pool like a hosepipe!

Ed W

Re: [gentoo-hardened] Running short of entropy...

[Magnus Granberg]

torsdag 11 mars 2010 00.30.24 skrev  Ed W:
> On 09/03/2010 08:16, Michael Orlitzky wrote:
> > I posted one to Bugzilla if you don't mind maintaining your own
> > overlays. Once it gets re-assigned and I've had enough coffee to
> > understand their FAQ, I might try to get it committed to sunrise.
> >
> > http://bugs.gentoo.org/show_bug.cgi?id=308599
> 
> Wow - that thing is filling the entropy pool like a hosepipe!
> 
> Ed W
> 
SSP use /dev/urandom, see the code in glibc
and it use only 4 bytes of urandom at a time.
dev/urandom will not be emty but the entopy will get more predictable when 
entopy pool is geting low.

Hardened-dev overlay
Magnus Grenberg (Zorry) <zorry@ume.nu>