cgi-session-user

[Cgi-session-user] FW: Security issue about CGI::Session

[Sherzod R. <she...@ha...>]

> -----Original Message-----
> From: Julien Danjou [mailto:ju...@da...] 
> Sent: Monday, March 20, 2006 12:27 PM
> To: Sherzod Ruzmetov
> Subject: Security issue about CGI::Session
> 
> 
> Hello,
> 
> I just saw you released 4.09, fixing security holes.
> However, it seems that at least the "file" driver is still 
> vulnerable, since it does not use the O_EXCL flag. What do you think ?
> 
> Do you plan to fix this and the sqlite holes ?
> 
> Regards,
> -- 
> Julien Danjou
> // <ju...@da...>     http://julien.danjou.info
> // 9A0D 5FD9 EB42 22F6 8974  C95C A462 B51E C2FE E5CD
> // I'm no superman.
> 

Re: [Cgi-session-user] FW: Security issue about CGI::Session

[Matt L. <mle...@cp...>]

Sherzod,

Just to make this public for why I applied things the way I did, I 
decided not to include O_EXCL in sysopen for the file driver's store 
method specifically because the file is quite likely to already exist 
(ie the next time the person returns to your site). This is why the code 
now checks for symlinks prior to opening the file for writing and 
attempts to delete the file and returns an error if failing the 
deletion. If we wish to use O_EXCL on all sysopen calls, we can delete 
the file prior to writing. However, this is a suboptimal solution if we 
proceed with the flush-by-default in param strategy.

Now for the db_file driver. For storage, this one has the same deal. The 
database is created in a file and we would rather have it stay around so 
using the O_EXCL flag creates problems. We protect against symlinks by 
deleting the literal symlink and, failing deletion, returning an error. 
Using O_EXCL for the lockfile would be ok if we could guarantee that it 
never exists, which we cannot (since we want to wait on the lock and not 
fail on the open). Thus all of these cases are protected by symlink 
checks which was the reason to use O_EXCL in the first place. I 
temporarily excluded O_EXCL from retrieve in db_file in the last release 
to pass tests (a pretty stupid mistake slipped through for 4.08) but the 
symlink checks are still in effect for retrieve as well. The fix has 
been committed and the next release will have O_EXCL for retrieve.

On the subject of the sqlite driver, we have no control over the 
creation of the sqlite database used with the sqlite driver. Perhaps we 
should add a note to the driver's pod that due diligence should be taken 
when creating the sqlite database and setting the database file's 
permissions?

Thanks,
Matt LeBlanc

Sherzod Ruzmetov wrote:
>   
>> -----Original Message-----
>> From: Julien Danjou [mailto:ju...@da...] 
>> Sent: Monday, March 20, 2006 12:27 PM
>> To: Sherzod Ruzmetov
>> Subject: Security issue about CGI::Session
>>
>>
>> Hello,
>>
>> I just saw you released 4.09, fixing security holes.
>> However, it seems that at least the "file" driver is still 
>> vulnerable, since it does not use the O_EXCL flag. What do you think ?
>>
>> Do you plan to fix this and the sqlite holes ?
>>
>> Regards,
>> -- 
>> Julien Danjou
>> // <ju...@da...>     http://julien.danjou.info
>> // 9A0D 5FD9 EB42 22F6 8974  C95C A462 B51E C2FE E5CD
>> // I'm no superman.
>>
>>     

Re: [Cgi-session-user] FW: Security issue about CGI::Session

[Kenneth P. <sh...@se...>]

On Tuesday, March 21, 2006 2:17 PM -0600 Matt LeBlanc <mle...@cp...> 
wrote:

> This is why the code now checks for symlinks prior to opening the file
> for writing and attempts to delete the file and returns an error if
> failing the deletion.

Don't you still have a window of vulnerability between the delete and 
create when a malicious local process could recreate the symlink?

Re: [Cgi-session-user] FW: Security issue about CGI::Session

[Matt L. <mle...@cp...>]

Kenneth,

Good point. I've submitted yet another patch that checks to make certain 
the file opened is not a symlink.

Now that I've reread the documentation for sysopen, it seems O_EXCL is 
only effective if it's paired with O_CREAT. I've verified that 
O_RDONLY|O_EXCL follows symlinks on three operating systems. Anyway, I'm 
currently writing new tests to make certain the file and db_file drivers 
protect against symlinks.

Thanks,
Matt LeBlanc

Kenneth Porter wrote:
> On Tuesday, March 21, 2006 2:17 PM -0600 Matt LeBlanc 
> <mle...@cp...> wrote:
>
>> This is why the code now checks for symlinks prior to opening the file
>> for writing and attempts to delete the file and returns an error if
>> failing the deletion.
>
> Don't you still have a window of vulnerability between the delete and 
> create when a malicious local process could recreate the symlink?
>

Re: [Cgi-session-user] FW: Security issue about CGI::Session

[Kenneth P. <sh...@se...>]

On Tuesday, March 21, 2006 5:00 PM -0600 Matt LeBlanc <mle...@cp...> 
wrote:

> Good point. I've submitted yet another patch that checks to make certain
> the file opened is not a symlink.

You might want to look at source to mkstemp(3) to see if there's any other 
conditions to worry about.

Re: [Cgi-session-user] FW: Security issue about CGI::Session

[Matt L. <mle...@cp...>]

All right gang,

I've added O_NOFOLLOW to pretty much any and all file operations for the 
file and db_file drivers. O_EXCL|O_CREAT is used to create files. There 
are also two new symlink tests to make certain the drivers don't follow 
any symlinks and remove symlinks before writing to session files. 
Hopefully, this ends this series of bugs.

Btw, if you have svn access, please test the db_file driver. I was 
getting some fairly odd issues when using O_NOFOLLOW and an older 
version of Berkeley DB. (upgrade fixed it)

Thanks,
Matt LeBlanc

RE: [Cgi-session-user] FW: Security issue about CGI::Session

[Sherzod R. <she...@ha...>]

All the tests passed for me with Berkeley DB 4.1.25, and DB_File.pm
1.806

> -----Original Message-----
> From: cgi...@li... 
> [mailto:cgi...@li...] On 
> Behalf Of Matt LeBlanc
> Sent: Wednesday, March 22, 2006 5:12 PM
> To: cgi...@li...
> Subject: Re: [Cgi-session-user] FW: Security issue about CGI::Session
> 
> 
> All right gang,
> 
> I've added O_NOFOLLOW to pretty much any and all file 
> operations for the 
> file and db_file drivers. O_EXCL|O_CREAT is used to create 
> files. There 
> are also two new symlink tests to make certain the drivers 
> don't follow 
> any symlinks and remove symlinks before writing to session files. 
> Hopefully, this ends this series of bugs.
> 
> Btw, if you have svn access, please test the db_file driver. I was 
> getting some fairly odd issues when using O_NOFOLLOW and an older 
> version of Berkeley DB. (upgrade fixed it)
> 
> Thanks,
> Matt LeBlanc
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking 
> scripting language that extends applications into web and 
> mobile media. Attend the live webcast and join the prime 
> developer group breaking into this new coding territory! 
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Cgi-session-user mailing list Cgi...@li...
https://lists.sourceforge.net/lists/listinfo/cgi-session-user