Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72672
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.169 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <5302ABF6.60407@sugarcrm.com>
References: <CAPhkiZxqmUVR3MhdMUBUuKxxkXndoTdoffbfuQ0oGc5JMvQ8dg@mail.gmail.com>
 <CAGa2bXbBnPQHqBUxe=S3HZtvQHQLdomEM4CEF3F+O0mf4oaktA@mail.gmail.com>
 <CAPhkiZx2sFqDmvdAsxOqqcrN6P09HW7MzFOA0cZbZ_2ruN4izw@mail.gmail.com>
 <CAGa2bXZbiTk_a=aJJY4iUPPaNQbv0yhyU2t6dXv2hAo0atiTdA@mail.gmail.com> <5302ABF6.60407@sugarcrm.com>
Date: Tue, 18 Feb 2014 10:46:31 +0900
Message-ID: <CAGa2bXbeGGFHJe8t7=9yDpuODWRq9+eVSeQ339j=1gzd4x9wGA@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: Andrey Andreev <narf@devilix.net>, "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e0160b6186c06c104f2a473f3
Subject: Re: [PHP-DEV] [VOTE] Secure Session Module Options/Internal by Default
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--089e0160b6186c06c104f2a473f3
Content-Type: text/plain; charset=UTF-8

Hi Stas,

On Tue, Feb 18, 2014 at 9:40 AM, Stas Malyshev <smalyshev@sugarcrm.com>wrote:

> > Length check is trivial, then why not check  and discard by module
> instead
>
> I don't really understand - what is the point of checking length? If you
> have session adoption problem, checking length won't help since the
> length is public. If you don't have this problem, checking length adds
> nothing since the session won't be valid anyway. So why add code that
> contributes nothing? Maybe I do not see some contribution, if so, please
> explain.
>

The reason why I would like to add length check is "use_strict_mode"
suffers grater risk of timing attack. I'll use the same scenario in
previous mail.

When "use_strict_mode=on", attacker sends short session ID many times to
see if the char matches part of session ID or not. When underlying data
storage is vulnerable to timing attack, timing is leaked. i.e.
stat(session_data_file_name) could be timing unsafe.

When "use_strict_mode=off", attacker sends session ID character one by one
and all of them are accepted as valid session data files. Since attacker's
invalid short session ID data is created as valid session ID data, attacker
cannot measure timing difference for the targeted session ID (1st one in
the directory entry) Window for attacker is rather small, but attacker may
succeed as long as timing is not safe, though.


> There is threat and it could be removed with length check.
> > Let's have the check and forget about timing attack!
>
> But there's no actual real-world threat - there is an imagined scenario
> which requires use of antique filesystems with very specific and
> unobvious properties (namely, directories stored sorted by name and
> having linear checks), and even in this case length check does not help,
> since again, session ID length is public and so nothing prevents one
> from using the correct length from the start. So length check does not
> fix the timing attack even in the unlikely case such attack would
> actually exist. It's like putting a locked door in an open field, and
> claiming it protects from robbers, despite there being nothing to be
> robbed and the door can be easily walked around. I really don't see a
> point here, especially as a user setting. I could see it as an internal
> check - defensive coding and all - where length is pre-calculated and
> checked internally. This is fine - but as a user setting that inevitably
> will be set wrong and cause trouble - I just don't see the point.


htree is safe.  Weak hash could be issue. Most of us remember hash
collision attack few years ago. (e.g mm save handler uses very simple hash.
It would be difficult to attack still, though.) However, B+tree could be
attackable. B tree is worse. User may use B+tree/B tree based session
storage and it is not obsolete/rare unlike liner directory search.

With minimum length, attacker must guess char combinations of that length
regardless of underlying session data storage.

The reason why I proposed this as user setting is user may have prefixed
session ID. If this is the case, internally set minimum length could be
useless.

Minimum session ID length solves all issues/anxieties and we may leave
timing attack behind as long as users set appropriate value to it.

Regards,

P.S. I would like to close doors for attacker as many as possible if
counter measure is feasible. This is my intention.

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--089e0160b6186c06c104f2a473f3--