Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Linux Kernel SMP "/proc" Race Condition Denial of Service (Not Critical)
Quote:
Description:
Tony Griffiths has reported a vulnerability in the Linux Kernel, which can be exploited malicious, local users to cause a DoS (Denial of Service).
The vulnerability is cause due to a memory corruption error in the "dentry_unused" list within the "prune_dcache()" function. This can be exploited to crash the kernel when running on SMP hardware by causing a race condition such that one or more tasks exit while another task is reading their /proc entries.
The vulnerability has been reported in versions 2.6.15 through 2.6.17. Other versions may also be affected.
Solution:
Grant only trusted users access to affected systems.
Secunia is currently not aware of an official version addressing this.
NETFILTER: SCTP conntrack: fix crash triggered by packet without chunks
When a packet without any chunks is received, the newconntrack variable
in sctp_packet contains an out of bounds value that is used to look up an
pointer from the array of timeouts, which is then dereferenced, resulting
in a crash.
Both releases address a core dump handling vulnerability:
Quote:
fix prctl privilege escalation and suid_dumpable
During security research, Red Hat discovered a behavioral flaw in core
dump handling. A local user could create a program that would cause a
core file to be dumped into a directory they would not normally have
permissions to write to. This could lead to a denial of service (disk
consumption), or allow the local user to gain root privileges.
We have a bad interaction with both the kernel and user space being able
to change some of the /proc file status. This fixes the most obvious
part of it, but I expect we'll also make it harder for users to modify
even their "own" files in /proc.
UPDATE: Linux 2.6.16.26 and 2.6.17.6 were released shortly after, to relax the /proc fix a bit. Because this patch isn't in and of itself a vulnerability fix, I will not be making a new post for it (this thread is only for vulnerabilities, not just any bugfixes).
Quote:
Clearign all of i_mode was a bit draconian. We only really care about
S_ISUID/ISGID, after all.
It's three patches, one of which addresses a security vulnerability:
Quote:
USB serial ftdi_sio: Prevent userspace DoS
This patch limits the amount of outstanding 'write' data that can be
queued up for the ftdi_sio driver, to prevent userspace DoS attacks (or
simple accidents) that use up all the system memory by writing lots of
data to the serial port.
It consists of many patches, one of which addresses a security vulnerability:
Quote:
USB serial ftdi_sio: Prevent userspace DoS
This patch limits the amount of outstanding 'write' data that can be
queued up for the ftdi_sio driver, to prevent userspace DoS attacks (or
simple accidents) that use up all the system memory by writing lots of
data to the serial port.
This is CVE-2006-2936 (this was patched in 2.6.16.y over a week ago).
Linux Kernel Ext3 Invalid Inode Number Denial of Service
Quote:
James McKenzie has reported a vulnerability in Linux Kernel, which can be exploited by malicious users to cause a DoS (Denial of Service).
The vulnerability is caused due to an error in ext3 when handling an invalid inode number. This can be exploited by sending a specially crafted NFS request with a V2 procedure (e.g. V2_LOOKUP) that specifies an invalid inode number.
Successful exploitation causes the exported directory to be remounted read-only.
The vulnerability has been reported in versions 2.6.14.4, 2.6.17.6, and 2.6.17.7. Other versions may also be affected.
It consists of a great deal of maintenance patches over 2.4.32, several of which address security vulnerabilities. Here's the essence, as far as patches with CVE IDs are concerned:
Quote:
[NETFILTER]: Fix do_add_counters race, possible oops or info leak (CVE-2006-0039)
Quote:
[SCTP]: Validate the parameter length in HB-ACK chunk. (CVE-2006-1857)
Quote:
[SCTP]: Respect the real chunk length when walking parameters. (CVE-2006-1858)
NOTE: I realize it might be a little odd to see the 2.4.x kernel make it into this thread. But considering that 2.4.x is still in such wide use, I feel it's important we post vulnerability reports for it also. Furthermore, the release of 2.4.33 seems like the perfect time to start doing so IMHO.
sctp_make_abort_user() now takes the msg_len along with the msg
so that we don't have to recalculate the bytes in iovec.
It also uses memcpy_fromiovec() so that we don't go beyond the
length allocated.
It is good to have this fix even if verify_iovec() is fixed to
return error on overflow.
UPDATE: Linux 2.6.17.11 has been released, but because it doesn't seem to include any fixes for security vulnerabilities, a new post here isn't warranted.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
