www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - zero-ing is not enough

reply "John Colvin" <john.loughran.colvin gmail.com> writes:
http://www.daemonology.net/blog/2014-09-06-zeroing-buffers-is-insufficient.html

D could incorporate something like this, no?
Sep 07 2014
next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 07.09.2014 19:00, schrieb John Colvin:

 http://www.daemonology.net/blog/2014-09-06-zeroing-buffers-is-insufficient.html


 D could incorporate something like this, no?


There are some posts on the HN discussion, stating that the problem is 
not so easy to solve.

Even without the C compiler related issues, there is a whole OS and 
hardware stack where the data can be attacked at multiple levels.

--
Paulo
Sep 07 2014
parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Sunday, 7 September 2014 at 17:24:46 UTC, Paulo Pinto wrote:

 Am 07.09.2014 19:00, schrieb John Colvin:

 http://www.daemonology.net/blog/2014-09-06-zeroing-buffers-is-insufficient.html


 D could incorporate something like this, no?


 There are some posts on the HN discussion, stating that the 
 problem is not so easy to solve.

 Even without the C compiler related issues, there is a whole OS 
 and hardware stack where the data can be attacked at multiple 
 levels.

 --
 Paulo


Every little helps?

This isn't my area, I just saw the article and thought it might 
be of interest.
Sep 07 2014
parent Paulo Pinto <pjmlp progtools.org> writes:
Am 07.09.2014 19:30, schrieb John Colvin:

 On Sunday, 7 September 2014 at 17:24:46 UTC, Paulo Pinto wrote:

 Am 07.09.2014 19:00, schrieb John Colvin:

 http://www.daemonology.net/blog/2014-09-06-zeroing-buffers-is-insufficient.html



 D could incorporate something like this, no?


 There are some posts on the HN discussion, stating that the problem is
 not so easy to solve.

 Even without the C compiler related issues, there is a whole OS and
 hardware stack where the data can be attacked at multiple levels.

 --
 Paulo


 Every little helps?

 This isn't my area, I just saw the article and thought it might be of
 interest.


Sure, I fully agree with you. Already not having C's faults helps a lot.

This is the post I have read, maybe you saw it as well.

https://news.ycombinator.com/item?id=8279687

--
Paulo
Sep 07 2014
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
John Colvin:


 http://www.daemonology.net/blog/2014-09-06-zeroing-buffers-is-insufficient.html

 D could incorporate something like this, no?


See:
https://d.puremagic.com/issues/show_bug.cgi?id=10661

Walter seems OK with adding something like that to the D 
intrinsics.

Bye,
bearophile
Sep 09 2014
next sibling parent reply "matovitch" <camille.brugel laposte.net> writes:
On Tuesday, 9 September 2014 at 07:09:52 UTC, bearophile wrote:

 John Colvin:


 http://www.daemonology.net/blog/2014-09-06-zeroing-buffers-is-insufficient.html

 D could incorporate something like this, no?


 See:
 https://d.puremagic.com/issues/show_bug.cgi?id=10661

 Walter seems OK with adding something like that to the D 
 intrinsics.

 Bye,
 bearophile


I am by no mean a security expert and this article scared me *a 
lot*. Are there any truly secure TLS implementation ?

There may be room for an  crypto attribute where the stack, the 
registers or the dynamically allocated memory would be zeroed out 
in the end ? But as stated in the comments, it's probably more of 
an OS job since a program may always crash.
Sep 09 2014
parent "Kagamin" <spam here.lot> writes:
On Tuesday, 9 September 2014 at 13:05:34 UTC, matovitch wrote:

 I am by no mean a security expert and this article scared me *a 
 lot*. Are there any truly secure TLS implementation ?

 There may be room for an  crypto attribute where the stack, the 
 registers or the dynamically allocated memory would be zeroed 
 out in the end ? But as stated in the comments, it's probably 
 more of an OS job since a program may always crash.


I'd say, it's easier to steal the entire key sitting in your heap 
(as heartbleed did it) than gather obscure traces from registers.
Sep 09 2014
prev sibling parent reply "David Nadlinger" <code klickverbot.at> writes:
On Tuesday, 9 September 2014 at 07:09:52 UTC, bearophile wrote:

 John Colvin:


 http://www.daemonology.net/blog/2014-09-06-zeroing-buffers-is-insufficient.html

 D could incorporate something like this, no?


 See:
 https://d.puremagic.com/issues/show_bug.cgi?id=10661

 Walter seems OK with adding something like that to the D 
 intrinsics.


Nope, the article is about something different. Quote: "With a 
bit of care and a cooperative compiler, we can zero a buffer — 
but that's not what we need."

David
Sep 09 2014
next sibling parent "Dominikus Dittes Scherkl" writes:
On Tuesday, 9 September 2014 at 14:42:14 UTC, David Nadlinger 
wrote:

 On Tuesday, 9 September 2014 at 07:09:52 UTC, bearophile wrote:

 John Colvin:


 http://www.daemonology.net/blog/2014-09-06-zeroing-buffers-is-insufficient.html

 D could incorporate something like this, no?


 See:
 https://d.puremagic.com/issues/show_bug.cgi?id=10661

 Walter seems OK with adding something like that to the D 
 intrinsics.


 Nope, the article is about something different. Quote: "With a 
 bit of care and a cooperative compiler, we can zero a buffer — 
 but that's not what we need."


Yeah. But volatileMemset() is a first step in the right direction.
Maybe we can have an attribute  local that advises the compiler 
not to do any optimization that copies stuff around and that it 
has to clear all used registers at function exit - that would be 
really secure and at the same time convenient for programming 
cryptography.
Sep 09 2014
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/9/2014 7:42 AM, David Nadlinger wrote:

 On Tuesday, 9 September 2014 at 07:09:52 UTC, bearophile wrote:

 John Colvin:


 http://www.daemonology.net/blog/2014-09-06-zeroing-buffers-is-insufficient.html

 D could incorporate something like this, no?


 See:
 https://d.puremagic.com/issues/show_bug.cgi?id=10661

 Walter seems OK with adding something like that to the D intrinsics.


 Nope, the article is about something different. Quote: "With a bit of care and
a
 cooperative compiler, we can zero a buffer — but that's not what we need."


1. The compiler has -gx, which will "stomp" the stack upon function return.

2. A "volatileMemset" should be added to druntime, per 10661

3. A function, say, "clearRegisters" should be added to druntime that zeros out 
all scratch registers.

I know the ycombinator article says that is insufficient, but these are still 
things that people are going to ask for and we should provide.
Sep 09 2014
next sibling parent "David Nadlinger" <code klickverbot.at> writes:
On Tuesday, 9 September 2014 at 18:59:33 UTC, Walter Bright wrote:

 1. The compiler has -gx, which will "stomp" the stack upon 
 function return.

 2. A "volatileMemset" should be added to druntime, per 10661

 3. A function, say, "clearRegisters" should be added to 
 druntime that zeros out all scratch registers.

 I know the ycombinator article says that is insufficient, but 
 these are still things that people are going to ask for and we 
 should provide.


Just to be clear, I don't disagree that this can be useful for 
certain applications. I just wanted to point out that what we 
were discussing something in 10661 is different from what the 
linked article discusses.

David
Sep 09 2014
prev sibling parent reply "Dominikus Dittes Scherkl" writes:
On Tuesday, 9 September 2014 at 18:59:33 UTC, Walter Bright wrote:

 1. The compiler has -gx, which will "stomp" the stack upon 
 function return.


Nice. But this will be set for the whole program.
But if I want to use e.g. a crypto-library, the rest of the 
program should not be slowed by stomping the stack all the time, 
only the library-functions that need this.


 2. A "volatileMemset" should be added to druntime, per 10661


Good.


 3. A function, say, "clearRegisters" should be added to 
 druntime that zeros out all scratch registers.


Good.


 I know the ycombinator article says that is insufficient, but 
 these are still things that people are going to ask for and we 
 should provide.


I think an attribute to prohibit "copying around"-optimizations 
would still be usefull in addition - together with the other 
three additions we should come close to what was intended by that 
article.
Maybe this can also avoid caches? (would be a mayor slowdown, but 
some will do what whatever is necessary to calm their paranoia...)
Sep 10 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/10/2014 3:34 AM, Dominikus Dittes Scherkl wrote:

 On Tuesday, 9 September 2014 at 18:59:33 UTC, Walter Bright wrote:

 1. The compiler has -gx, which will "stomp" the stack upon function return.


 Nice. But this will be set for the whole program.
 But if I want to use e.g. a crypto-library, the rest of the program should not
 be slowed by stomping the stack all the time, only the library-functions that
 need this.


This is incorrect, it would apply only to the module being compiled. If you 
compile the crypto code with a separate command to dmd, then only that code is 
affected.
Sep 10 2014
parent "Dominikus Dittes Scherkl" writes:
On Wednesday, 10 September 2014 at 19:19:09 UTC, Walter Bright 
wrote:

 On 9/10/2014 3:34 AM, Dominikus Dittes Scherkl wrote:

 On Tuesday, 9 September 2014 at 18:59:33 UTC, Walter Bright 
 wrote:

 1. The compiler has -gx, which will "stomp" the stack upon 
 function return.


 Nice. But this will be set for the whole program.
 But if I want to use e.g. a crypto-library, the rest of the 
 program should not
 be slowed by stomping the stack all the time, only the 
 library-functions that
 need this.


 This is incorrect, it would apply only to the module being 
 compiled. If you compile the crypto code with a separate 
 command to dmd, then only that code is affected.


Ah, yes. Ok thats also very cool. So cyptography programmed in D 
makes it a lot harder for the hackers :-)
But of course not enought for the very paranoid...
Sep 11 2014