6759683 2001-07-17 16:05 +0930 /35 rader/ Toby Corkindale <tjcorkin@sa.pracom.com.au> Sänt av: joel@lysator.liu.se Importerad: 2001-07-17 19:10 av Brevbäraren Extern mottagare: Keith Owens <kaos@ocs.com.au> Extern kopiemottagare: bugtraq@securityfocus.com Mottagare: Bugtraq (import) <18041> Kommentar till text 6759255 av Keith Owens <kaos@ocs.com.au> Ärende: Re: insmod/modprobe behaviour in regards to non-root-owned modules ------------------------------------------------------------ From: Toby Corkindale <tjcorkin@sa.pracom.com.au> To: Keith Owens <kaos@ocs.com.au> Cc: <bugtraq@securityfocus.com> Message-ID: <Pine.LNX.4.33.0107171558290.26570-100000@localhost.localdomain> josh@pulltheplug.com posted to bugtraq earlier today with a case whereby modules.dep is set to mode 0666, and thus can be manipulated by a non-root user to cause a common module to load a user-owned evil module. According to his post, Linux kernels from 2.4.3 onwards have a default empty umask, and thus on some distributions that do not explicity set the umask in time, a world-writeable modules.dep is created on bootup. This can be seen as a configuration error, perhaps, but I question whether modprobe should bypass the root-ownership test, which seems like a good idea. I guess there are cases where being able to specify an intentionally-non-root-owned module would be useful, but is that enough of a reason to bypass the security check? -Toby On Tue, 17 Jul 2001, Keith Owens wrote: > modules.dep is a trusted file. root builds it by hand or via a startup > script. If root changes the modules without refreshing modules.dep > then you have GIGO. > > AFAICT you need root to do this, to update files and/or permissions in > /lib/modules. If you can reproduce the problem without requiring root > privileges at some stage and without using depmod -r then it is a bug. > Otherwise "root can destroy a system", this is not news. (6759683) /Toby Corkindale <tjcorkin@sa.pracom.com.au>/(Ombruten) Kommentar i text 6759874 av Keith Owens <kaos@ocs.com.au> 6759874 2001-07-17 16:51 +1000 /31 rader/ Keith Owens <kaos@ocs.com.au> Sänt av: joel@lysator.liu.se Importerad: 2001-07-17 19:41 av Brevbäraren Extern mottagare: Toby Corkindale <tjcorkin@sa.pracom.com.au> Extern kopiemottagare: bugtraq@securityfocus.com Mottagare: Bugtraq (import) <18042> Kommentar till text 6759683 av Toby Corkindale <tjcorkin@sa.pracom.com.au> Ärende: Re: insmod/modprobe behaviour in regards to non-root-owned modules ------------------------------------------------------------ From: Keith Owens <kaos@ocs.com.au> To: Toby Corkindale <tjcorkin@sa.pracom.com.au> Cc: bugtraq@securityfocus.com Message-ID: <4389.995352692@kao2.melbourne.sgi.com> On Tue, 17 Jul 2001 16:05:56 +0930 (CST), Toby Corkindale <tjcorkin@sa.pracom.com.au> wrote: >josh@pulltheplug.com posted to bugtraq earlier today with a case whereby >modules.dep is set to mode 0666, and thus can be manipulated by a non-root >user to cause a common module to load a user-owned evil module. Fixed in 2.4.7-pre7, not released yet. It is a kernel bug, not modutils. >According to his post, Linux kernels from 2.4.3 onwards have a default empty >umask, and thus on some distributions that do not explicity set the umask >in time, a world-writeable modules.dep is created on bootup. > >This can be seen as a configuration error, perhaps, but I question whether >modprobe should bypass the root-ownership test, which seems like a good >idea. >I guess there are cases where being able to specify an >intentionally-non-root-owned module would be useful, but is that enough of a >reason to bypass the security check? You must explicitly bypass the security check by running insmod -r for an individual module or depmod -r for all modules. Frankly I hate the idea but some people share systems and deliberately set their /lib/modules to 777 with modules.dep being 666. Foot, gun, shoot. (6759874) /Keith Owens <kaos@ocs.com.au>/-----------