>Number:         5996
>Category:       lib
>Synopsis:       lib/libc/db/hash/* writes memory garbage to db file
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    lib-bug-people (Library Bug People)
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Wed Aug 19 23:05:00 1998
>Last-Modified:
>Originator:     ITOH Yasufumi
>Organization:
	Nara Institute of Science and Technology, Nara, Japan
>Release:        1.3G (Aug. 19, 1998)
>Environment:
System: NetBSD acha.my.domain 1.3G NetBSD 1.3G (UVM) #0: Mon Aug 17 09:10:00 JST 1998 itohy@myname.my.domain:/usr/src/sys/arch/x68k/compile/UVM x68k


>Description:
	lib/libc/db/hash/* uses uninitialized memory allocated with malloc(3)
	and writes it to the .db file.

	This is a potential security weekness.

	(This seems not a security hole *for now*, and this pr doesn't
	 belong to security/*.  The hash db is used by cap_mkdb and pwd_mkdb;

	    cap_mkdb	doesn't handle any secure data on NetBSD
			(used for termcap.db and vgrindefs.db),

	    pwd_mkdb	handles secure data, but it doesn't issue free(3)
			for the data before the db library uses malloc()
			(it uses static (not malloc'ed) buffer for line buffer
			 and create spwd.db after pwd.db).

	 However, this may be changed in the future,
	 and I think it worth fixing.)

>How-To-Repeat:
	On NetBSD, the malloc()ed memory is often cleard by zero,
	and this problem seem no revealed except for spwd.db
	(spwd.db has memory garbage).
	I noticed this on my cross environment on Solaris.

	If you want to see this appear, try this:

	1. Insert  memset(ptr, 0xff, length)  after every invocation
	   of malloc() in lib/libc/db/hash/* and re-create libc, cap_mkdb,
	   and pwd_mkdb, and generate the db files.

	2. Then, change the memset to  bzero(ptr, length)
	   and create the db's again.

	3. Compare the output db files from 1. and 2.,
	   and you will see them different.

>Fix:
	The memory to be written to file should be cleard.
	's/malloc(/calloc(1, /' is a usable workaround but not a good fix.
	Is it more efficient to use mmap()?
>Audit-Trail:
>Unformatted: