* make-string uninitialized memory eposure considered harmful
@ 2003-01-10 19:54 Greg Troxel
2003-01-10 15:51 ` Egil Moeller
` (2 more replies)
0 siblings, 3 replies; 6+ messages in thread
From: Greg Troxel @ 2003-01-10 19:54 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: make-string uninitialized memory eposure considered harmful
2003-01-10 19:54 make-string uninitialized memory eposure considered harmful Greg Troxel
@ 2003-01-10 15:51 ` Egil Moeller
2003-01-11 11:41 ` Mikael Djurfeldt
2003-01-12 17:45 ` Marius Vollmer
2003-01-10 20:56 ` Thien-Thi Nguyen
2003-01-11 6:52 ` tomas
2 siblings, 2 replies; 6+ messages in thread
From: Egil Moeller @ 2003-01-10 15:51 UTC (permalink / raw)
Cc: guile-user
> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: make-string uninitialized memory eposure considered harmful
2003-01-10 15:51 ` Egil Moeller
@ 2003-01-11 11:41 ` Mikael Djurfeldt
2003-01-12 17:45 ` Marius Vollmer
1 sibling, 0 replies; 6+ messages in thread
From: Mikael Djurfeldt @ 2003-01-11 11:41 UTC (permalink / raw)
Cc: Greg Troxel
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: make-string uninitialized memory eposure considered harmful
2003-01-10 15:51 ` Egil Moeller
2003-01-11 11:41 ` Mikael Djurfeldt
@ 2003-01-12 17:45 ` Marius Vollmer
1 sibling, 0 replies; 6+ messages in thread
From: Marius Vollmer @ 2003-01-12 17:45 UTC (permalink / raw)
Cc: Greg Troxel
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: make-string uninitialized memory eposure considered harmful
2003-01-10 19:54 make-string uninitialized memory eposure considered harmful Greg Troxel
2003-01-10 15:51 ` Egil Moeller
@ 2003-01-10 20:56 ` Thien-Thi Nguyen
2003-01-11 6:52 ` tomas
2 siblings, 0 replies; 6+ messages in thread
From: Thien-Thi Nguyen @ 2003-01-10 20:56 UTC (permalink / raw)
Cc: guile-user
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: make-string uninitialized memory eposure considered harmful
2003-01-10 19:54 make-string uninitialized memory eposure considered harmful Greg Troxel
2003-01-10 15:51 ` Egil Moeller
2003-01-10 20:56 ` Thien-Thi Nguyen
@ 2003-01-11 6:52 ` tomas
2 siblings, 0 replies; 6+ messages in thread
From: tomas @ 2003-01-11 6:52 UTC (permalink / raw)
Cc: guile-user
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2003-01-12 17:45 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-01-10 19:54 make-string uninitialized memory eposure considered harmful Greg Troxel
2003-01-10 15:51 ` Egil Moeller
2003-01-11 11:41 ` Mikael Djurfeldt
2003-01-12 17:45 ` Marius Vollmer
2003-01-10 20:56 ` Thien-Thi Nguyen
2003-01-11 6:52 ` tomas
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).