hello everyone, I am Rishabh...I am a 19 year old student at the University of Texas at Austin.I am presently in The hague in Holland where my parents live. I have been using linux for the past year. now as you might assume i do not have much of an idea of the kernel level activities of a LINUX system. i have no idea what was written in this message.anyone have the time to decode it for me.also could you please tell me if there are patches already avaliable for the vulnerability.I am running kernel 2.4.23 on a debian system. thanks a lot. Rishabh Manocha
On Mon, 5 Jan 2004, Raj Mathur wrote: > [Your distribution vendor will be bringing out a new kernel soon. > Please upgrade if you use kernel 2.2, 2.4 or 2.6 -- Raju] > > This is an RFC 1153 digest. > (1 message) > ---------------------------------------------------------------------- > > MIME-Version: 1.0 > Message-ID: <[EMAIL PROTECTED]> > From: Paul Starzetz <[EMAIL PROTECTED]> > Sender: [EMAIL PROTECTED] > To: [EMAIL PROTECTED], <[EMAIL PROTECTED]>, > <[EMAIL PROTECTED]> > Subject: [Full-Disclosure] Linux kernel mremap vulnerability > Date: Mon, 5 Jan 2004 13:30:32 +0100 (CET) > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Synopsis: Linux kernel do_mremap local privilege escalation vulnerability > Product: Linux kernel > Version: 2.2, 2.4 and 2.6 series > Vendor: http://www.kernel.org/ > URL: http://isec.pl/vulnerabilities/isec-0012-mremap.txt > CVE: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0985 > Author: Paul Starzetz <[EMAIL PROTECTED]>, Wojciech Purczynski > <[EMAIL PROTECTED]> > Date: January 5, 2004 > > > Issue: > ====== > > A critical security vulnerability has been found in the Linux kernel > memory management code in mremap(2) system call due to incorrect bound > checks. > > > Details: > ======== > > The mremap system call provides functionality of resizing (shrinking or > growing) as well as moving across process's addressable space of exist > ing virtual memory areas (VMAs) or any of its parts. > > A typical VMA covers at least one memory page (which is exactly 4kB on > the i386 architecture). An incorrect bound check discovered inside the > do_mremap() kernel code performing remapping of a virtual memory area > may lead to creation of a virtual memory area of 0 bytes length. > > The problem bases on the general mremap flaw that remapping of 2 pages > from inside a VMA creates a memory hole of only one page in length but > an additional VMA of two pages. In the case of a zero sized remapping > request no VMA hole is created but an additional VMA descriptor of 0 > bytes in length is created. > > Such a malicious virtual memory area may disrupt the operation of other > parts of the kernel memory management subroutines finally leading to un > expected behavior. > > A typical process's memory layout showing invalid VMA created with > mremap system call: > > 08048000-0804c000 r-xp 00000000 03:05 959142 /tmp/test > 0804c000-0804d000 rw-p 00003000 03:05 959142 /tmp/test > 0804d000-0804e000 rwxp 00000000 00:00 0 > 40000000-40014000 r-xp 00000000 03:05 1544523 /lib/ld-2.3.2.so > 40014000-40015000 rw-p 00013000 03:05 1544523 /lib/ld-2.3.2.so > 40015000-40016000 rw-p 00000000 00:00 0 > 4002c000-40158000 r-xp 00000000 03:05 1544529 /lib/libc.so.6 > 40158000-4015d000 rw-p 0012b000 03:05 1544529 /lib/libc.so.6 > 4015d000-4015f000 rw-p 00000000 00:00 0 > [*] 60000000-60000000 rwxp 00000000 00:00 0 > bfffe000-c0000000 rwxp fffff000 00:00 0 > > The broken VMA in the above example has been marked with a [*]. > > > Impact: > ======= > > Since no special privileges are required to use the mremap(2) system > call any process may misuse its unexpected behavior to disrupt the ker > nel memory management subsystem. Proper exploitation of this vulnerabil > ity may lead to local privilege escalation including execution of arbi > trary code with kernel level access. Proof-of-concept exploit code has > been created and successfully tested giving UID 0 shell on vulnerable > systems. > > The exploitability of the discovered vulnerability is possible, although > not a trivial one. We have identified at least two different attack vec > tors for the 2.4 kernel series. All users are encouraged to patch all > vulnerable systems as soon as appropriate vendor patches are released. > > > Credits: > ======== > > Paul Starzetz <[EMAIL PROTECTED]> has identified the vulnerability and > performed further research. COPYING, DISTRIBUTION, AND MODIFICATION OF > INFORMATION PRESENTED HERE IS ALLOWED ONLY WITH EXPRESS PERMISSION OF > ONE OF THE AUTHORS. > > > Disclaimer: > =========== > > This document and all the information it contains are provided "as is", > for educational purposes only, without warranty of any kind, whether ex > press or implied. > > The authors reserve the right not to be responsible for the topicality, > correctness, completeness or quality of the information provided in > this document. Liability claims regarding damage caused by the use of > any information provided, including any kind of information which is in > complete or incorrect, will therefore be rejected. > > - -- > Paul Starzetz > iSEC Security Research > http://isec.pl/ > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.7 (GNU/Linux) > > iD8DBQE/+Vj2C+8U3Z5wpu4RApegAKCOkWCWg8Jy/y9S1WtEWxerkkQNbQCgk/X9 > 8aGjOA7fTT8EynIFw/sgoHU= > =Aw61 > -----END PGP SIGNATURE----- > > > _______________________________________________ > Full-Disclosure - We believe in it. > Charter: http://lists.netsys.com/full-disclosure-charter.html > > ------------------------------ > > End of this Digest > ****************** > > -- > Raj Mathur [EMAIL PROTECTED] http://kandalaya.org/ > GPG: 78D4 FC67 367F 40E2 0DD5 0FEF C968 D0EF CC68 D17F > It is the mind that moves > > > ------------------------------------------------------- > This SF.net email is sponsored b _______________________________________________ ilugd mailing list [EMAIL PROTECTED] http://frodo.hserus.net/mailman/listinfo/ilugd
