[vox-tech] 2.4.20 zlib support?

[ME]

Peter Jay Salzman said:
> there's a new "major catagory" in 2.4.20: "library routines".  under
> that, there are two options: compression and decompression support for
> zlib.  no help files for it.
>
> anyone know what kernel-space libz style support is for?  is the kernel
> now compressing portions of itself on the fly or something zany like
> that?

I had a guess on the purpose... (background)

Issues have come up with zlib in the past. Older copies of the zlib libs
permited exploits and this lead to headlines in bugtraq for a while. The
problems in zlib were *big*. Many apps use zlib, and though many dyn link
against the zlib on your system, not all need to do this, and some link to
zlib staticly. (This meant upgrading you zlib may not be enough to
"secure" the system against zlib expolts.) Then again, some are
commercial/proprietary and though "strings" may provide you with some
information in the application, that is not guarantee for detecting use of
zlib in an application. (obfuscation, etc.)

I seem to recall the bug in zlib that was exploited was based on
allocation of space for decompressing not being big enough for the actual
content (carefully crafted content).

My guess, was that the zlib kernel routines are designed to permit the
kernel to deal with this issue by controlling the space allocation and
allowing an extra layer of security if an application should use an
insecure zlib.

Now, the actual content of the docs suggest there is a relation to this.
It appears as though the zlib stuff for 2.4.20 is a replacement for zlib.
However, it appears as though apps must use the provided *.h files before
they can take advantage of this.

From: /usr/src/linux-2.4.20/lib/zlib_inflate/Makefile :
#
# This is a modified version of zlib, which does all memory
# allocation ahead of time.
#
# This is only the decompression, see zlib_deflate for the
# the compression
#
# Decompression needs to be serialized for each memory
# allocation.
#
# (The upsides of the simplification is that you can't get in
# any nasty situations wrt memory management, and that the
# uncompression can be done without blocking on allocation).
#

>From the paired zlib_deflate a similar comment:
#
# This is a modified version of zlib, which does all memory
# allocation ahead of time.
#
# This is the compression code, see zlib_inflate for the
# decompression code.
#

I would have expected a *lot* of discussion on the inclusion of parts of
lib routines into the kernel/kernel-space, but have not found much yet.

Anyone else?

-ME




-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS/CM$/IT$/LS$/S/O$ !d--(  ) !s !a   (-----) C  $(    ) U    $( $) P $>
L   $(  ) E W   $( ) N  o K w $>  >    O-@ M $ V-$>- !PS !PE Y  PGP
t@-(  ) 5 @ X@ R- tv- b   DI    D  G--@ e >  >     h(  )>  r*>? z?
------END GEEK CODE BLOCK------
decode: http://www.ebb.org/ungeek/ about: http://www.geekcode.com/geek.html
  Campus IT(/OS Security): Operating Systems Support Specialist Assistant