Re: Code updates

Mark Swanson wrote:

>On November 18, 2002 07:56 pm, Alex Kramarov wrote:
>  
>
>>The gzip compression code in tux dates back to 1999. the security
>>vurnerability in gzip library was discovered this year. Is the code used by
>>tux includes any vurnerable code ?
>>
My assumption is that, yes, it is indeed vulnerable.  This is of course 
an assumption with no other basis than what you have already deduced: 
the code predates the fix, and since the bug was announced, I have seen 
nothing that implies fixing it.  I'm sure someone would like to take 
credit for it if it was done.  Pure conjecture.  I doubt it makes you 
feel better, but that's all I can offer and it's better than talking 
into dead space.

None of the work done in the last few weeks has gone into gzip.c at all.

>Perhaps no one wants to stick there neck out and say it is ok :-)
>
It probably isn't.

>I'm not going to say if it is ok or not, but I'll note a couple of things 
>after a quick grep or two:
>
>1. a grep of deflate *.c shows nothing but gzip.c
>2. nothing seems to use any inflate keyword except gzip.c
>
>If you enable the compression proc entry, my understanding was that no gzip.c 
>code was used and that the .gz file (if present) would simply be sent instead 
>of the .html file. This makes sense as it would be best to run gzip locally 
>to compress all of your html/css/js files before serving them.
>
>If this guess is correct then there would be no vunerability because no gzip 
>code would execute. I am beginning to wonder what would happen if gzip.c was 
>deleted and you recompiled...
>  
>
This is not necessarily true.  While I had some trouble keeping up with 
the code flow sometimes mostly due to the relatively large number of 
goto statements, I did notice something interesting.  Apparently it was 
someone's intention to have TUX actually compress items on the 
filesystem before sending them down the wire.  According to the code, a 
value of 2 sent to net/tux/compression would enable this behavior. 
 Totally undocumented as far as I can tell and I have absolutely no idea 
if it works as I consider it to be a horrible idea.  If I want 
everything in a document tree compressed, I'll do it myself or set up a 
cron job.  I don't consider it the job of the kernel.  But that's just 
my opinion of course.  That said, it never even occured to me to try 
turning it on.  And as far as I can tell, it is the only reason why 
gzip.c exists as part of TUX (unless there's something in the FTP code 
-- can't see why though).

So my haphazard take on things are as follows: the gzip code is probably 
vulnerable, TUX has incomplete support for on-the-fly compression, and 
if you aren't using the on-the-fly compression, it's not in the code 
path and therefore not a security issue.

- Miles