[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#22202: 24.5; SECURITY ISSUE -- Emacs Server vulnerable to random num
From: |
Paul Eggert |
Subject: |
bug#22202: 24.5; SECURITY ISSUE -- Emacs Server vulnerable to random number generator attack on Windows systems |
Date: |
Mon, 18 Jan 2016 12:50:12 -0800 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 |
Eli Zaretskii wrote:
I wish we'd discuss such things before committing and not after.
Sorry, I missed the part of the discussion that talked about reading
/dev/urandom in the first place.
. I see nothing wrong with having 2 (or more) independent reads from
/dev/urandom:
It's one more thing to worry about when auditing an Emacs trace. Also, it's two
file descriptors (both open at the same time) when we can get by with just one.
. GnuTLS is a separate library, so it's free to do that for its
own purposes; we shouldn't care.
Yes and no. Yes, we shouldn't care how GnuTLS gets entropy; and no, because if
GnuTLS is available we should be better off using its entropy source than
rolling our own. The GnuTLS guys are far more expert in this stuff; why reinvent
the wheel? And if the GnuTLS entropy source is busted, Emacs is already insecure
in dozens of important ways, so using that source here shouldn't make matters
significantly worse.
Besides, what if tomorrow
there will be a 3rd library that would need to access
/dev/urandom?
Not our problem. As you say, libraries are free to do that for their own
purposes, and we shouldn't care.
. GnuTLS is a library for TLS, not for cryptography.
GnuTLS is not just for TLS, it's for secure communications. Getting a nonce is a
basic building block for such a library. They're not going to remove a basic
building block.
What if tomorrow GnuTLS changes its implementation?
That's fine. We don't need to know the details of how GnuTLS gets its nonces.
For example, if it starts using the RDRAND instruction available on Ivy Bridge
and later Intel processors, more power to them. We shouldn't care.
. This change means that we now load GnuTLS at startup, even if no
TLS connections are or will be used.
That's already true on GNU and POSIXish platforms, so it's not a problem there.
It is an issue on MS-Windows, though, so your change to avoid GnuTLS here on
MS-Windows makes sense.
Why is it suddenly a concern that users will know that we use time and
PID as fallback?
Merely because we're in the neighborhood anyway and it's the first time I
noticed that this detail was documented. The detail doesn't belong in the
documentation; Emacs shouldn't promise that it'll use the PID, for example.
One other thing, while we're nearby: the doc shouldn't assume that readers know
that time-of-day etc. is less random.
How about the attached patch? It should address these documentation concerns.
t.diff
Description: Text Data
- bug#22202: 24.5; SECURITY ISSUE -- Emacs Server vulnerable to random number generator attack on Windows systems, (continued)
bug#22202: 24.5; SECURITY ISSUE -- Emacs Server vulnerable to random number generator attack on Windows systems, Eli Zaretskii, 2016/01/18
- bug#22202: 24.5; SECURITY ISSUE -- Emacs Server vulnerable to random number generator attack on Windows systems,
Paul Eggert <=
- bug#22202: 24.5; SECURITY ISSUE -- Emacs Server vulnerable to random number generator attack on Windows systems, Eli Zaretskii, 2016/01/18
- bug#22202: 24.5; SECURITY ISSUE -- Emacs Server vulnerable to random number generator attack on Windows systems, Paul Eggert, 2016/01/19
- bug#22202: 24.5; SECURITY ISSUE -- Emacs Server vulnerable to random number generator attack on Windows systems, Eli Zaretskii, 2016/01/19
- bug#22202: 24.5; SECURITY ISSUE -- Emacs Server vulnerable to random number generator attack on Windows systems, John Wiegley, 2016/01/19
- bug#22202: 24.5; SECURITY ISSUE -- Emacs Server vulnerable to random number generator attack on Windows systems, Paul Eggert, 2016/01/19
- bug#22202: 24.5; SECURITY ISSUE -- Emacs Server vulnerable to random number generator attack on Windows systems, Eli Zaretskii, 2016/01/19
Message not availablebug#22202: 24.5; SECURITY ISSUE -- Emacs Server vulnerable to random number generator attack on Windows systems, Andy Moreton, 2016/01/19
bug#22202: 24.5; SECURITY ISSUE -- Emacs Server vulnerable to random number generator attack on Windows systems, Glenn Morris, 2016/01/19
Message not availablebug#22202: 24.5; SECURITY ISSUE -- Emacs Server vulnerable to random number generator attack on Windows systems, Andy Moreton, 2016/01/20
bug#22202: 24.5; SECURITY ISSUE -- Emacs Server vulnerable to random number generator attack on Windows systems, Eli Zaretskii, 2016/01/20