Re: make-string uninitialized memory eposure considered harmful

Re: make-string uninitialized memory eposure considered harmful

[Egil Moeller]

> At this point, I get what is going on.  This is confusing, and exposes
> the contents of random memory locations, perhaps exposing a password
> that somone thought had been garbage collected.  So, I'd argue that
> the default behavior should be to fill with nulls, or something, even
> though the spec should remain unspecified.  If we are afraid people
> will depend on that, it can fill with something chosen arbitrarily,
> but it shouldn't expose the existing contents of free memory.
>
> Anyone want to call me paranoid?

Yes, you are. But not entierly... I don't think that make-string is broken
in any way - random data that comes from old values in the program are
as good as any other values for the purpose of undefined characters...
But, you hit an interresting problem - one might think of a situation when
one would like to be able to create a string (or other object?) that, when
garbage-collected, was guaranteed to be overwritten with 0's. Is this
doable? It would require one more type-bit in all datatypes that would
support this behaviour. Also, such a bit would need to be copied whenever
the object was copied or parts of it extracted or merged with other
objects.

I'm quite interrested in this, as I have written a wrapper around GnuPG
(using the C-wrapper GpgME) for Guile (if you are interrested in it, it is
currently a bit too integrated with the rest of a bigger project, but it
is allready fully functional (you can sign, encrypt, veryfy and decrypt
messages in memmory), but in the end, I hope to release it as a separate
project)...

/Egil

-- 
http://redhog.org
GPG Public key: http://redhog.org/PGP%20Public%20key.asc
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

make-string uninitialized memory eposure considered harmful

[Greg Troxel]

In guile 1.6, NetBSD 1.6-stable/i386, I found that make-string returns
random stuff if you don't give it a second arg.  

guile> (make-string 100)
"traced-stack-ids set of stack ids for which tracing is active. executable is in no way restricted"

This I took to be a sign of brokenness.  So I read the docs:

guile> (help make-string)
`make-string' is a primitive procedure in the (guile) module.

 - Scheme Procedure: make-string k [chr]
     Return a newly allocated string of length K.  If CHR is given,
     then all elements of the string are initialized to CHR, otherwise
     the contents of the STRING are unspecified.

 
and tried again.

guile> (make-string 1000)
"make-stack

 - Scheme Procedure: make-stack obj . args
     Create a new stack. If OBJ is `#t', the current evaluation stack
     is used for creating the stack frames, otherwise the frames are
     taken from OBJ (which must be either a debug object or a
     continuation).

     ARGS should be a list containing any combination of integer,
     procedure and `#t' values.

     These values specify various ways of cutting away uninteresting
     stack frames from the top and bottom of the stack that
     `make-stack' returns.  They come in pairs like this: `(INNER_CUT_1
     OUTER_CUT_1 INNER_CUT_2 OUTER_CUT_2 ...)'.

     Each INNER_CUT_N can be `#t', an integer, or a procedure.  `#t'
     means to cut away all frames up to but excluding the first user
     module frame.  An integer means to cut away exactly that number of
     frames.  A procedure means to cut away all frames up to but
     excluding the application frame whose procedure matches the
     specified one.

     Each OUT"

At this point, I get what is going on.  This is confusing, and exposes
the contents of random memory locations, perhaps exposing a password
that somone thought had been garbage collected.  So, I'd argue that
the default behavior should be to fill with nulls, or something, even
though the spec should remain unspecified.  If we are afraid people
will depend on that, it can fill with something chosen arbitrarily,
but it shouldn't expose the existing contents of free memory.

Anyone want to call me paranoid?


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: make-string uninitialized memory eposure considered harmful

[Thien-Thi Nguyen]

   From: Greg Troxel <gdt@ir.bbn.com>
   Date: Fri, 10 Jan 2003 14:54:02 -0500

   Anyone want to call me paranoid?

you are paranoid, guile doesn't need to be, and guile users should
understand their security policies enough to know when to choose to be.
i.e., this is a programmer discipline issue.  if guile were to enforce
nul on init, there would be no way to provide the current O(1) behavior.
since the opposite is not true, it is better.

thi


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: make-string uninitialized memory eposure considered harmful

[tomas]

On Fri, Jan 10, 2003 at 02:54:02PM -0500, Greg Troxel wrote:
> In guile 1.6, NetBSD 1.6-stable/i386, I found that make-string returns
> random stuff if you don't give it a second arg.  
> 
> guile> (make-string 100)
> "traced-stack-ids set of stack ids for which tracing is active. executable is in no way restricted"
> 
> This I took to be a sign of brokenness.  So I read the docs:

[rest deleted]

Hmm. I'd tend to agree with the other posters here.
I had the impression that it is the job of the routine
holding the sensitive data to make sure that they don't
stay around (swap space seems to be a worse can of worms,
since it stays around for longer).

Regards
-- tomas


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: make-string uninitialized memory eposure considered harmful

[Mikael Djurfeldt]

Egil Moeller <redhog@redhog.org> writes:

> one might think of a situation when one would like to be able to
> create a string (or other object?) that, when garbage-collected, was
> guaranteed to be overwritten with 0's. Is this doable?

(define-module (utils self-destruct)
  #:export (make-self-destructing-string))

(define guard-string (make-guardian))

(define (make-self-destructing-string k)
  (let ((s (make-string k)))
    (guard-string s)
    s))

(define (destroy-strings)
  (cond ((guard-string)
	 =>
	 (lambda (s)
	   (string-fill! s #\nul)
	   (destroy-strings)))))

(add-hook! after-gc-hook destroy-strings)

M


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: make-string uninitialized memory eposure considered harmful

[Marius Vollmer]

Egil Moeller <redhog@redhog.org> writes:

> But, you hit an interresting problem - one might think of a situation when
> one would like to be able to create a string (or other object?) that, when
> garbage-collected, was guaranteed to be overwritten with 0's. Is this
> doable?

Mikael has shown how to do it, but I would say that in general, there
are no security in Guile (in the sense that they are in Java, say).
Guile is supposed to be a 'safe' language and if things like buffer
overflows are detected, they will get fixed, but I don't think we want
to make any official guarantees about the security model of (ice-9
safe), say.  We don't want to do this since the problem is hard and
needs to be done completely until we can claim security as a feature.
It's no use saying "modules ave a sophisticated ownership and
permission protocal" when you can easily subvert it.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user