Issue #5741 has been updated by Martin Bosslet.


Thanks for your thoughts!

>  I think you're going to adopt opt-in way, so library/application
>  developers must add String#clear call after using the password, right?

Yes, I think opt-in is the only way to ensure there are no negative side 
effects on existing code.

>  If it's opt-in, new specific class would be enough I think.  In this
>  way, we can control the memory copy (part-of, of course) and eventually
>  we might be able to split buffers into multiple parts that have
>  different addresses.
>  
>  class SecureByteBuffer
>    def ==(rhs)
>      raise unless rhs.is_a?(SecureByteBuffer)
>      ...
>    end
>  
>    def clear
>      ...
>    end
>  end

That is an interesting approach, I'd love to catch up on this. So
far, I had four ideas for implementing such a thing.

1. String#clear 
+ it's at the "root" of the problem
+ adoption of the feature will merely ask for calling #clear on password variables at the right places
- invasive because rarely needed
- memory side effects of other string ops might be hard to keep in sync

2. Decorator/Visitor/Subclass of String
+ Unobtrusive
- But adoption requires a lot more code changes, not only the "erasure" part but also the parts
where the passwords are created

3. Module/Class function class, "helper function"
+ Unobtrusive
- Adoption requires only the additional calls at the place where erasure is needed
- Where to put this?

4. Separate class, not necessarily String-like
+ Unobtrusive
- Adoption again requires lots of changes (like in 2.)
- Will it be accepted by users?

If I understand correctly your proposal would tend towards 4.?
I'm open to anything, as long as there's something :) I haven't 
looked at the memory copy issue yet in detail, so I can't really
tell for sure whether it's possible at all to control it entirely.
Might as well be the case that we would need to document safe
handling of passwords properly to ensure the desired outcome. I'd
volunteer for that once we have found a stable solution.
 
>  But the most hard part I think is how we construct this Object...

I know... :)
  
>  Martin, do you have concrete examples which needs secure erasure of
>  passwords?  Only I can think of now is ossl_pem_passwd_cb in
>  ext/openssl.  It gets password as a String from a callback block but it
>  would be good to add a feature to read from STDIN directly, without
>  creating the String object.

Besides the cases within the OpenSSL extension that you mentioned, I was
mainly thinking about authentication in web apps. You typically retrieve
the password String from a request there. I need to dig deeper to come
up with some concrete examples but I assume the idea should be clear.

Besides that I kept thinking about what you said the other day, whether
I'm only concerned about passwords or also about private keys and the like.
I was only thinking passwords when I wrote this, but you're absolutely right,
private keys in memory are equally bad [1].

It happens a lot that we use private keys in this way, SSH, SSL, digital signatures,
encryption, you name it. And the biggest problem is that the private keys are
not strings in general, so the String solution wouldn't apply directly. But I'm
confident that we could at least apply the same technique. Fortunately, OpenSSL takes
care of this for us in all places where we rely on OpenSSL (with its OPENSSL_cleanse 
function), but still we should investigate if there aren't any loopholes left.

[1] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.77.3297&rep=rep1&type=pdf

----------------------------------------
Feature #5741: Secure Erasure of Passwords
https://bugs.ruby-lang.org/issues/5741

Author: Martin Bosslet
Status: Open
Priority: Normal
Assignee: 
Category: 
Target version: 2.0.0


In other languages it is considered good practice to securely erase 
passwords immediately after they were used. Imagine authentication
in a web app - ultimately a String containing the password arrives
at the server, where it will be processed and compared to some 
previously stored value. After this is done, there is no need to
store these password Strings any longer, so they should be
discarded right away (more on why later).

In C, you would simply overwrite the array of bytes with zeroes or
random values. In Java, Strings are immutable, that's why there it
is common practice to use char[] for all things password and overwrite
them when done.

Currently, there is no way in Ruby to overwrite the memory that
was used by a String. String#clear and String#replace both use
str_discard internally, which only frees the underlying pointer 
without overwriting it.

The problem with not erasing passwords is this: the contents of the
String stay in memory until they are finally GC'ed. But even then
only the pointer will be freed, leaving the contents mostly intact
until the memory is reclaimed and overwritten later on.

This could be exploited if an attacker had access to the memory of
the server. This could happen in many ways: a core dump after a
crash, access to the host if the server runs in a VM, or even by
deep-freezing the DRAM :) [1]

It could be argued that given the examples above, much more 
devastating attacks would be possible since in all of those
cases you more or less have physical access to the machine. But
I would still consider this to be a valid concern, if not only
for the reason of never opening additional attack surfaces if
they can be avoided relatively easily.

I also found [2], which seems to show that Python deals with 
similar problems and it also contains more background info.

Eric Hodel and I discussed this yesterday and Eric came up with
a C extension that can be used to illustrate the problem (attached).

If you inspect the resulting core dump, you will find the following:

- the untouched String remains in memory fully intact
- the String#clear'ed String remains to a large extent, typically the
  first character is missing - so if you typed "PASSWORD", search for
  "ASSWORD" (unintentional pun) instead
- The String#clear_secure'ed will have been completely erased, no 
  traces remain

My questions:

1. Would you agree that we need this functionality?
2. Where would we ideally place it? I'm not sure whether
   String is the perfect place, but on the other hand, String
   is the only place where we have access to the implementation
   details.
3. Are there better alternative ways how we could achieve this?

[1] http://www.schneier.com/blog/archives/2008/02/cold_boot_attac.html
[2] http://stackoverflow.com/questions/728164/securely-erasing-password-in-memory-python


-- 
http://redmine.ruby-lang.org