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

[vendor-sec] Some problems (fwd)


if anyone has some free time and wants to look into these and send me
patches (by tomorrow) I would be very happy to let someone else do the
work! ;^)

People might also like to get a heads up on the problems Olaf has



----- Forwarded message from Olaf Kirch -----
From: Olaf Kirch
Subject: Some problems

Hi Andrew,

I was looking into linux-pam for potential security problems about
two weeks ago and found some minor problems with it, which I'm now
forwarding to you FYI. However I was glad to find that most of the code
seems very robust.

I lost the notes I made when I cleaned up my desk, so I have to collect
them from memory. This is all wrt. pam 0.58 and pwdb 0.54.

 1.	File locking: when locking files, pam (or was it libpwdb?)
	tries to work some NFS magic by first creating a temp lock
	file, linking it to the real lock file, and making certain the
	link count equals 2 after the file is created.

	The problem with this is that if the /tmp directory is on the
	same disk as /etc (which it is more often than not), an attacker
	can create a hard link to the lock file between the file's
	creation and the link count check.

	Fortunately, it's not straightforward to turn this into a DoS
	exploit as the locking process records its pid in the file and
	when the next process comes around, it will check whether the
	process with the recorded pid is still alive, and if it isn't,
	simply remove the lock file. The attacker could try to fork
	processes until the kernel's pid counter wraps around, but there
	doesn't seem to be a way how he can obtain the lock pid. He may
	be able to do so by scanning /etc for the temp lock file name,
	which contains the pid. Otherwise, he may simply try to grab
	a range of pids.

	[This kind of 'NFS compatibility' also makes for nice DoS
	attacks on user mailboxes if the mail spool is mode 1777
	and the mail reader performs this kind of warped check on

	There's also a naming problem with the lock files. Most utilities
	I've seen expect the name of the lock file for /etc/passwd to
	be /etc/ptmp, while libpwdb uses /etc/pwd.lock.

 2.	pam_access: The first problem is that when it comes to the
	local host name, it calls uname(2) and extracts utsname.machine
	-- which returns i586 on my box. This is used for user name
	matches of the type 'user@fromhost'. In this case it always
	compares fromhost to i586...  At least kind of surprising.

	The second problem is with address patterns. If you specify
	1.2.3. in access.conf, the test will match any host whose
	FQDN starts with 1.2.3.

 3.	pam_listfile: with item=group, the code appears to do weird
	things. It first puts the user's primary group on itemlist,
	and then goes on to append member names from the first couple
	of groups getgrent happens to return:

	for(i=1; (i < 255) && (grpinfo = getgrent()); i++) {
		    itemlist[i++] = xstrdup(grpinfo->gr_mem[j++]);

	Fortunately this code will most likely dump core anyway
	(note the double increment on i, and the missing bounds check
	in the inner loop)

	I guess what was intended was something like this:

	for(i=1; (i < 255) && (grpinfo = getgrent());) {
		if (is_on_list(grpinfo->gr_mem, citemp))
		    itemlist[i++] = xstrdup(grpinfo->gr_name);

 4.	pam_rhost: Blindly assumes that whatever gethostbyname returns
	is an IPv4 address, and matches that.

I admit that I'm not very familiar with the PAM internals, so some of the
issues raised may in fact be non-issues, or I may be wrong because I
misunderstood the code.

----- End of forwarded message from Olaf Kirch -----

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