[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: zxid session max sub-directories



Eric Rybski wrote:
> Hi,
>
>    I believe zxid currently has a potential Denial of Service
> vulnerability
> due to the flat-directory organization of the ses/ session directory.
>  ext2/3 has a maximum limit of 32K sub-directories in any one directory.
>  Thus if a user were to rapidly initiate multiple new SAML sessions in a
> short period of time, they could max out this limit and cause new sessions
> to fail.  This scenario could also occur if zxid were to authenticate many
> different, valid users in a short period of time.  Site-specific session
> cleanup scripts would likely not be able to keep up with such a load
> (valid
> or malicious).
>
>    Has there been consideration of a directory hashing algorithm to store
> session directories?  Given a configurable number of directory levels, 2

One way to mitigate this is to use a modern file system that does not have
such low limit on directory entries. Quite frankly I thought ext3 already
did not have this limit. I know for fact that reiserfs, Veritas FS, and
ext4 do not have the limit. I also belive the default filesystem of
Solaris 8 or newer is free from this defect.

> chars per level, and a relatively even distribution of session GUID keys,
> this should dramatically reduce namespace utilization in any one directory
> to eliminate a site-wide DoS attempt, and mitigate the directory limit
> issue
> enough for custom session expiration tools (based on a site policy) to
> keep
> up with cleanup without ever reaching the max in any sub-directory.  (2-3
> sub-levels should be sufficient for most sites.)

Hashing means more complexity and more code, thus more opportunity
for bugs.

Perhaps the same effort could be more productively spent in
writing a true database backend for session management. Ideally
there would be a database independent layer to which plugins
for various databases, such as MySQL, BerkeleyDB, libmm, etc.

> This seems simple enough to implement, assuming there aren't obscure
> places
> to update in the code.  Would this be generally limited to cases
> identified
> by `egrep "(ZXID_SES_DIR|ses_arch_dir)" *.c` ?

Although I will not personally work towards directory hashing, I am
willing to integrate code by others, provided that the hashing part is
conditioned by #ifded USE_DIR_HASHING or some such.

Cheers,
--Sampo

> Thanks,
> Eric