Re: Concerns about the use of OPENSSL_cleanse()

[Richard Levitte - VMS Whacker]

For y'all that have concerns about this: I'll take a look tomorrow,
and see what I may have done wrong (not an excluded possibility :-)).

-- 
Richard Levitte   \ Spannvägen 38, II \ [EMAIL PROTECTED]
Redakteur@Stacken  \ S-168 35  BROMMA  \ T: +46-8-26 52 47
\  SWEDEN   \ or +46-708-26 53 44
Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/

Unsolicited commercial email is subject to an archival fee of $400.
See  for more info.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Concerns about the use of OPENSSL_cleanse()

[bpringlemeir]

> Jeffrey Altman wrote:

 >> I think we need to take a very close look at the situations when
 >> it is safe to replace memset(buf,0,sizeof(buf)) with
 >> OPENSSL_cleanse(buf,sizeof(buf)).  It is clearly safe to make this

[snip]

 Ben> OPENSSL_cleanse() should be followed by a memset()? OTOH, if the
 Ben> result of memset() is used, then it can't be optimised away...

 Yoram> Same concerns are raised while trying to gain performance by
 Yoram> reusing the SSL structure, instead of reallocating it for new
 Yoram> connection establishment.  Using SSL_clear(SSL *s), as part of
 Yoram> the reuse flow, involves a call to OPENSSL_cleanse.

 Yoram> Following OPENSSL_cleanse with a call to memset() may result
 Yoram> with performance degradation. Are the OPENSSL_cleanse
 Yoram> replacements required in all cases ? Should we be able to
 Yoram> dynamically define which behavior is preferable ?

Configurable behaviour is certainly preferable for many embedded
applications.  Processes typically don't have the separation on
embedded apps that big iron boxes do.  I guess that there are many
instances where OpenSSL does things in order to prevent prying eyes on
the same box.

I can appreciate this on my Linux machine.  However, most people
wouldn't want this on a router.  Perhaps a macro like the NO_MD5, etc
could be used.  I know that the BIO's make this rather slick for the
ciphers.  Conditionalization of counter-measures against host
originating attacks might be much more difficult to implement.

fwiw,
Bill Pringlemeir.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Concerns about the use of OPENSSL_cleanse()

[Geoff Thorpe]

Hello,

On December 9, 2002 01:17 am, Wirta Ville wrote:
> Just a humble opinnion on that problem. How about adding a normal
> memset to be the last action that OPENSSL_cleanse() does? Would that
> make any kind of sence or improvement? That way the compiler would have
> to make sure OpenSSL can safely expect to find a NULL from a memset:ed
> pointer field? There may or may not actually be NULL values, but that
> doesn't matter because OPENSSL_cleanse() has already put some random
> data in there. ...Or is this too simple idea to ever work? :-)

One obvious point is that OPENSSL_cleanse() serves two purposes;
  (1) intertwine the input/output dependencies of the "cleanse" logic with
  "malloc" so that compilers can't just throw the operation away.
  (2) sanitise memory

Adding a memset after the cleanse() destroys (1) ... the compiler knows 
that no matter what we do, the memory ends up blanked anyway so it may 
start to optimise stuff away (including possibly the memset as well). 
Also, memset(,0,) is not the best memory sanitisation one can manage - 
and arguably we should perhaps make OPENSSL_cleanse() configurable so 
that it can be looped more than once. If you allow that loop count to be 
set to zero then that could provide an option for disabling memory 
sanitisation altogether if people don't care... hmm. 

Anyway, w.r.t. adding a memset - I can't see how that improves anything 
and can see possibilities for it breaking things.

Cheers,
Geoff

-- 
Geoff Thorpe
[EMAIL PROTECTED]
http://www.geoffthorpe.net/

The bastards have beaten off rationalism for now, but haven't eliminated 
our capacity for reason - to do that they'd have to make us forget how
to both think and fear at the same time.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Concerns about the use of OPENSSL_cleanse()

[Jeffrey Altman]

Rich Salz wrote:


Hmm, so OpenSSL is depending on NULL being all-bytes-zero. :)


Funny about that.  :-)



Probably a safe assumption, although theoretically you shouldn't do that.


It really wouldn't matter what assumption you made.  At some point there 
needs to be a test:

 Is this structure initialized?

And assigning random values to a structure will never allow the test to 
properly succeed.


But this does make me think that perhaps a better approach is to have 
a bunch of static instances:
X509_STORE_ctx nil_x509_store_ctx;
RSA nil_RSA;
...
etc.

Then OPENSSL_cleanse is
  OPENSSL_cleanse2(volatile void* dest, volatile void* in, size_t s)
{
memcpy(dest, in, s);
/* play usual "force used" tricks here */
}

Another approach to consider is implementing special XXX_cleanse() 
functions that are smart about which fields can be randomized and which 
ones (ie, pointers) must be set to zero.



__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Concerns about the use of OPENSSL_cleanse()

[Rich Salz]

However, this is not true for data structures that are located on the 
heap.  In many cases OpenSSL provides functions that allow a buffer to 
be reused:  XXX_init(), XXX_cleanup(), XXX_free().  This is true for 
several data structures.  By replacing memset() with OPENSSL_cleanse() 
in the XXX_cleanup() function we have a problem when the data structure 
contains pointers to additional heap allocations. 


Hmm, so OpenSSL is depending on NULL being all-bytes-zero. :)

Probably a safe assumption, although theoretically you shouldn't do that.

But this does make me think that perhaps a better approach is to have a 
bunch of static instances:
	X509_STORE_ctx nil_x509_store_ctx;
	RSA nil_RSA;
...
etc.

Then OPENSSL_cleanse is
  OPENSSL_cleanse2(volatile void* dest, volatile void* in, size_t s)
	{
	memcpy(dest, in, s);
	/* play usual "force used" tricks here */
	}

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

RE: Concerns about the use of OPENSSL_cleanse()

[Yoram Zahavi]

Same concerns are raised while trying to gain performance by reusing the SSL
structure, instead of reallocating it for new connection establishment.
Using SSL_clear(SSL *s), as part of the reuse flow, involves a call to
OPENSSL_cleanse.

Following OPENSSL_cleanse with a call to memset() may result with
performance degradation. Are the OPENSSL_cleanse replacements required in
all cases ? Should we be able to dynamically define which behavior is
preferable ?

Yoram.

-Original Message-
From: Ben Laurie [mailto:[EMAIL PROTECTED]]
Sent: Mon, December 09, 2002 12:50 PM
To: [EMAIL PROTECTED]
Subject: Re: Concerns about the use of OPENSSL_cleanse()


Jeffrey Altman wrote:
> I think we need to take a very close look at the situations when it is 
> safe to replace memset(buf,0,sizeof(buf)) with 
> OPENSSL_cleanse(buf,sizeof(buf)). 
> It is clearly safe to make this replacement when the buffer is a stack 
> allocation because there can be no future use of the data can take 
> place.  So there is no functional difference between a buffer filled 
> with zeros and a buffer filled with garbage data.
> 
> However, this is not true for data structures that are located on the 
> heap.  In many cases OpenSSL provides functions that allow a buffer to 
> be reused:  XXX_init(), XXX_cleanup(), XXX_free().  This is true for 
> several data structures.  By replacing memset() with OPENSSL_cleanse() 
> in the XXX_cleanup() function we have a problem when the data structure 
> contains pointers to additional heap allocations. 
> One case that I found a problem with is:
> 
> . application allocates X509_STORE_CTX and initializes it with 
> X509_STORE_CTX_init(). 
> . application calls X509_STORE_CTX_cleanup() which in turn calls 
> OPENSSL_cleanse()
> 
> . application calls X509_STORE_CTX_free() which in turn calls 
> X509_STORE_CTX_cleanup().
> This results in an exception because the ex_data field is a struct that 
> contains pointers to memory allocations.  Due to the OPENSSL_cleanse() 
> call the pointer values are garbage non-NULL values.  An attempt is made 
> to free the memory.  This causes an exception.
> 
> This is going to require careful examination to find all of the places 
> where pointers need to be set to NULL after or during a cleanse operation.

OPENSSL_cleanse() should be followed by a memset()? OTOH, if the result 
of memset() is used, then it can't be optimised away...

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html   http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Concerns about the use of OPENSSL_cleanse()

[Ben Laurie]

Jeffrey Altman wrote:

I think we need to take a very close look at the situations when it is 
safe to replace memset(buf,0,sizeof(buf)) with 
OPENSSL_cleanse(buf,sizeof(buf)). 
It is clearly safe to make this replacement when the buffer is a stack 
allocation because there can be no future use of the data can take 
place.  So there is no functional difference between a buffer filled 
with zeros and a buffer filled with garbage data.

However, this is not true for data structures that are located on the 
heap.  In many cases OpenSSL provides functions that allow a buffer to 
be reused:  XXX_init(), XXX_cleanup(), XXX_free().  This is true for 
several data structures.  By replacing memset() with OPENSSL_cleanse() 
in the XXX_cleanup() function we have a problem when the data structure 
contains pointers to additional heap allocations. 
One case that I found a problem with is:

. application allocates X509_STORE_CTX and initializes it with 
X509_STORE_CTX_init(). 
. application calls X509_STORE_CTX_cleanup() which in turn calls 
OPENSSL_cleanse()

. application calls X509_STORE_CTX_free() which in turn calls 
X509_STORE_CTX_cleanup().
This results in an exception because the ex_data field is a struct that 
contains pointers to memory allocations.  Due to the OPENSSL_cleanse() 
call the pointer values are garbage non-NULL values.  An attempt is made 
to free the memory.  This causes an exception.

This is going to require careful examination to find all of the places 
where pointers need to be set to NULL after or during a cleanse operation.

OPENSSL_cleanse() should be followed by a memset()? OTOH, if the result 
of memset() is used, then it can't be optimised away...

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html   http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

RE: Concerns about the use of OPENSSL_cleanse()

[Wirta Ville]

Good morning great OpenSSL developpers!

Just a humble opinnion on that problem. How about adding a normal memset to
be the last action that OPENSSL_cleanse() does? Would that make any kind of
sence or improvement? That way the compiler would have to make sure OpenSSL
can safely expect to find a NULL from a memset:ed pointer field? There may
or may not actually be NULL values, but that doesn't matter because
OPENSSL_cleanse() has already put some random data in there. ...Or is this
too simple idea to ever work? :-)

T: VW


-Original Message-
From: Jeffrey Altman [mailto:[EMAIL PROTECTED]]
Sent: Monday, December 09, 2002 7:04 AM
To: [EMAIL PROTECTED]
Subject: Concerns about the use of OPENSSL_cleanse()


I think we need to take a very close look at the situations when it is 
safe to replace memset(buf,0,sizeof(buf)) with 
OPENSSL_cleanse(buf,sizeof(buf)).  

It is clearly safe to make this replacement when the buffer is a stack 
allocation because there can be no future use of the data can take 
place.  So there is no functional difference between a buffer filled 
with zeros and a buffer filled with garbage data.

However, this is not true for data structures that are located on the 
heap.  In many cases OpenSSL provides functions that allow a buffer to 
be reused:  XXX_init(), XXX_cleanup(), XXX_free().  This is true for 
several data structures.  By replacing memset() with OPENSSL_cleanse() 
in the XXX_cleanup() function we have a problem when the data structure 
contains pointers to additional heap allocations.  

One case that I found a problem with is:

. application allocates X509_STORE_CTX and initializes it with 
X509_STORE_CTX_init().  

. application calls X509_STORE_CTX_cleanup() which in turn calls 
OPENSSL_cleanse()

. application calls X509_STORE_CTX_free() which in turn calls 
X509_STORE_CTX_cleanup().
This results in an exception because the ex_data field is a struct that 
contains pointers to memory allocations.  Due to the OPENSSL_cleanse() 
call the pointer values are garbage non-NULL values.  An attempt is made 
to free the memory.  This causes an exception.

This is going to require careful examination to find all of the places 
where pointers need to be set to NULL after or during a cleanse operation.

- Jeff



__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Concerns about the use of OPENSSL_cleanse()

[Jeffrey Altman]

I think we need to take a very close look at the situations when it is 
safe to replace memset(buf,0,sizeof(buf)) with 
OPENSSL_cleanse(buf,sizeof(buf)).  

It is clearly safe to make this replacement when the buffer is a stack 
allocation because there can be no future use of the data can take 
place.  So there is no functional difference between a buffer filled 
with zeros and a buffer filled with garbage data.

However, this is not true for data structures that are located on the 
heap.  In many cases OpenSSL provides functions that allow a buffer to 
be reused:  XXX_init(), XXX_cleanup(), XXX_free().  This is true for 
several data structures.  By replacing memset() with OPENSSL_cleanse() 
in the XXX_cleanup() function we have a problem when the data structure 
contains pointers to additional heap allocations.  

One case that I found a problem with is:

. application allocates X509_STORE_CTX and initializes it with 
X509_STORE_CTX_init().  

. application calls X509_STORE_CTX_cleanup() which in turn calls 
OPENSSL_cleanse()

. application calls X509_STORE_CTX_free() which in turn calls 
X509_STORE_CTX_cleanup().
This results in an exception because the ex_data field is a struct that 
contains pointers to memory allocations.  Due to the OPENSSL_cleanse() 
call the pointer values are garbage non-NULL values.  An attempt is made 
to free the memory.  This causes an exception.

This is going to require careful examination to find all of the places 
where pointers need to be set to NULL after or during a cleanse operation.

- Jeff



__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]