Re: [VOTE] Secure Session Module Options/Internal by Default
Hi Andrey,
On Mon, Feb 17, 2014 at 10:22 PM, Andrey Andreev <[email protected]> wrote:
> This still doesn't explain how it would work.
> And why is it necessary as a setting instead of auto-detecting it? The
> valid length should be easy to calculate.
>
Valid length is easy to detect as well as valid chars.
Current session module only detects and discards "if session has invalid
chars"
i.e. Invalid chars are only few chars. Stricter check is up to session save
handlers.
http://lxr.php.net/xref/PHP_5_6/ext/session/session.c#1605
(It would be better to have stricter check in module. IMO. It's BC...)
Length check is trivial, then why not check and discard by module instead
of
accepting invalid session ID and let users check and discard? It addresses
bug
like null session ID raises annoying error also.
Timing attack could be done with liner directory search. With liner
directory
search, file names are compared one by one, character by character.
Therefore,
attacker can exploit timing if sent session ID matches or not.
Modern file systems like ext4 have htree that hashes file names. Timing
cannot be
used such file systems because it is the same as "hash strings, then
compare".
Characters are not compared one by one.
XFS uses B+tree. B+tree is one by one comparison basically. B+tree would be
harder to exploit since its structure may change a lot during attack, but
it might
be vulnerable if attacker considers tree structure change during attack.
i.e. Tree
structure may change after GC or new sessions are added. (This is also
applicable to liner directory search file system. Structure change is more
obvious
and easy to handle with simple liner search.)
There is threat and it could be removed with length check.
Let's have the check and forget about timing attack!
Regards,
P.S. The reason why Python adopts "hash comparison" with ==/=== is the
same reason, I suppose. PHP 5.6 may do the same or similar, and forget
about timing attack.
--
Yasuo Ohgaki
[email protected]
Thread (19 messages)