bug-gnu-emacs
[Top][All Lists]
Advanced

[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.

Attachment: t.diff
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]