Date: Wed, 06 Dec 2006 17:45:29 +0100 From: Dan Lukes <dan@obluda.cz> To: freebsd-security@freebsd.org Cc: Colin Percival <cperciva@freebsd.org> Subject: Re: FreeBSD Security Advisory FreeBSD-SA-06:25.kmem Message-ID: <4576F3A9.9000307@obluda.cz> In-Reply-To: <45769654.5050307@freebsd.org> References: <200612060933.kB69XErN083086@freefall.freebsd.org> <45769654.5050307@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Colin Percival napsal/wrote: >> A user in the "operator" group can read the contents of kernel memory. >> Such memory might contain sensitive information, such as portions of >> the file cache or terminal buffers. This information might be directly >> useful, or it might be leveraged to obtain elevated privileges in some >> way; for example, a terminal buffer might include a user-entered >> password. > > For what it's worth, there was a lot of debate about whether this deserved > an advisory: Members of the operator group are allowed (by default, at least) > to read raw disk devices, so being able to read kernel memory really isn't > very much of a privilege escalation. Even if the user with (unwanted) access memory has the read access to raw disk device we can't assume that all private data presend in memory are present on disk also. Especially when swap disabled. Paranoid application allocate non-swappable memory to store critical data also. There may be in-memory decrypted data (password supplied by user) that are never present on disk in raw form. Also, the PAM allow to configure the computer to authenticate users without passwords in master.passwd - but the correct and usable password still can be found in memory during authentication phase. Unless we can safelly assume that an user can't use the bug to acces data that isn't accesible via other interface, then we found new data channel. If we founded a new data channel where it should not be, then we found a point of possible data leakage. If data leak to someone who should not have acces to it, we found the security bug. There - someone has unwanted access to memory. It's security bug. The fact the user has the regular read-only access to raw disk device is irelevant unless all data avaiable in memory are avaiable on disk also. > I'd be interested to hear opinions from the FreeBSD community about whether > this sort of issue is one which anyone really cares about. Despite the fact that this bug don't create real security violation on any system under my supervision, I would like to know all informations that *may* affect security of a system. Including those you are not sure they really affect security or not. I'm administrator of system, I'm responsible for it's security, I will make final decision. I will ignore those information that doesn't claim security problem on my systems (but it still may claim security problem on other's system). Informations doesn't hurt. The lack of information may hurt. Dan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4576F3A9.9000307>