[#47790] [ruby-trunk - Bug #7097][Open] Thread locals don't work inside Enumerator — "tenderlovemaking (Aaron Patterson)" <aaron@...>

32 messages 2012/10/01
[#47791] [ruby-trunk - Bug #7097][Assigned] Thread locals don't work inside Enumerator — "kosaki (Motohiro KOSAKI)" <kosaki.motohiro@...> 2012/10/01

[#47792] Re: [ruby-trunk - Bug #7097][Assigned] Thread locals don't work inside Enumerator — Aaron Patterson <tenderlove@...> 2012/10/01

On Tue, Oct 02, 2012 at 03:05:17AM +0900, kosaki (Motohiro KOSAKI) wrote:

[#47798] Re: [ruby-trunk - Bug #7097][Assigned] Thread locals don't work inside Enumerator — SASADA Koichi <ko1@...> 2012/10/01

(2012/10/02 3:12), Aaron Patterson wrote:

[#47800] Re: [ruby-trunk - Bug #7097][Assigned] Thread locals don't work inside Enumerator — SASADA Koichi <ko1@...> 2012/10/01

(2012/10/02 8:22), SASADA Koichi wrote:

[#47832] [ruby-trunk - Feature #7106][Open] FileUtils.touch should allow touching the symlink itself rather than the file the link points to — "cirrusthinking (Alessandro Diaferia)" <alessandro@...>

18 messages 2012/10/04

[#47847] [ruby-trunk - Bug #7110][Open] CGI: Add support for HTML5 <header> tag — "stomar (Marcus Stollsteimer)" <redmine@...>

16 messages 2012/10/05

[#47870] [ruby-trunk - Bug #7123][Open] Segmentation fault in ruby 1.9.3-p194 — "mscottford (M. Scott Ford)" <scott@...>

13 messages 2012/10/09

[#47880] [ruby-trunk - Bug #7134][Open] Signal handling bug in Mac OS X — "auastro (Andy Kitchen)" <kitchen.andy+rubybug@...>

17 messages 2012/10/10

[#47881] [ruby-trunk - Bug #7135][Open] GC bug in Ruby 1.9.3-p194? — "alexdowad (Alex Dowad)" <alexinbeijing@...>

21 messages 2012/10/10

[#47887] [ruby-trunk - Bug #7137][Open] Date.parse overly lenient when attempting to parse Monday? — "garysweaver (Gary Weaver)" <garysweaver@...>

12 messages 2012/10/10

[#47930] [ruby-trunk - Feature #7148][Open] Improved Tempfile w/o DelegateClass — "Glass_saga (Masaki Matsushita)" <glass.saga@...>

14 messages 2012/10/12

[#47970] [ruby-trunk - Bug #7158][Open] require is slow in its bookkeeping; can make Rails startup 2.2x faster — "gregprice (Greg Price)" <price@...>

30 messages 2012/10/14

[#48027] [Backport93 - Backport #7172][Open] [[Ruby 1.9:]] fix rbconfig for --enable-load-relative (v2) — "mpapis (Michal Papis)" <mpapis@...>

13 messages 2012/10/16

[#48053] [ruby-trunk - Bug #7180][Open] set_trace_func with error in proc block locks up Ruby with 100% cpu usage and no way to exit without killing proc — "garysweaver (Gary Weaver)" <garysweaver@...>

8 messages 2012/10/17

[#48072] [ruby-trunk - Bug #7184][Open] --disable-gems commandline parameter does not show up with ruby -h — "steenslag (siep korteling)" <s.korteling@...>

10 messages 2012/10/18

[#48130] [ruby-trunk - Bug #7200][Open] Setting external encoding with BOM| — "brixen (Brian Ford)" <brixen@...>

14 messages 2012/10/21

[#48191] [ANN] 2.0.0 feature freeze — Yusuke Endoh <mame@...>

Japanese later; 日本語は後で

37 messages 2012/10/24
[#48696] Re: [ANN] 2.0.0 feature freeze — SASADA Koichi <ko1@...> 2012/11/01

(2012/10/24 5:39), Yusuke Endoh wrote:

[#48260] [ruby-trunk - Bug #7214][Open] Ruby 2.0 breaks support for some debugging tools — "banister (john mair)" <jrmair@...>

22 messages 2012/10/25

[#48315] [ruby-trunk - Bug #7220][Open] StringIO#initialize_copy causes aliasing between the objects — "brixen (Brian Ford)" <brixen@...>

13 messages 2012/10/26

[#48413] [ruby-trunk - Bug #7221][Open] Unable to compile kgio under 1.9.3 with error: ruby-1.9.3-<plvl>/lib/ruby/1.9.1/mkmf.rb:597:in `Integer': can't convert nil into Integer (TypeError) — "davidderyldowney (David Deryl Downey)" <me@...>

9 messages 2012/10/27

[#48549] [ruby-trunk - Feature #7240][Open] Inheritable #included/#extended Hooks For Modules — "apotonick (Nick Sutterer)" <apotonick@...>

14 messages 2012/10/29

[#48551] [ruby-trunk - Feature #7241][Open] Enumerable#to_h proposal — "nathan.f77 (Nathan Broadbent)" <nathan.f77@...>

23 messages 2012/10/29

[#48552] [ruby-trunk - Bug #7242][Open] Bignum mathematical accuracy regression in r31695 — "mhall (Matthew Hall)" <mhall@...>

11 messages 2012/10/29

[ruby-core:48361] [ruby-trunk - Feature #5741] Secure Erasure of Passwords

From: "ko1 (Koichi Sasada)" <redmine@...>
Date: 2012-10-26 21:30:34 UTC
List: ruby-core #48361
Issue #5741 has been updated by ko1 (Koichi Sasada).


ping. status?

I think matz doesn't know this ticket.
Could someone grab this ticket?

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

Author: MartinBosslet (Martin Bosslet)
Status: Assigned
Priority: Normal
Assignee: matz (Yukihiro Matsumoto)
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://bugs.ruby-lang.org/

In This Thread