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 "isdn_net_setcfg()" Buffer Overflow Vulnerability
Quote:
Description:
A vulnerability with unknown impact has been reported in the Linux Kernel.
The vulnerability is caused due to a boundary error within the "isdn_net_setcfg()" function in drivers/isdn/i4l/isdn_net.c when processing IOCTL configuration requests sent to the ISDN pseudo device (/dev/isdnctrl). This can be exploited to cause a buffer overflow via a specially crafted IIOCNETSCF IOCTL request.
Successful exploitation requires write access to /dev/isdnctrl.
The vulnerability is reported in version 2.6.23. Other versions may also be affected.
Linux Kernel "do_coredump()" Information Disclosure
Quote:
Description:
A security issue has been reported in the Linux Kernel, which can be exploited by malicious, local users to disclose potentially sensitive information.
The security issue is caused due to the "do_coredump()" function in fs/exec.c not correctly verifying the user ID of a core dump file when dumping the core into an existing file. This can be exploited to e.g. gain access to sensitive information by tricking an application with another user ID into dumping the core into a preexisting file.
The security issue is reported in 2.4.x and 2.6.x prior to 2.6.24-rc4.
Solution:
Fixed in the stable prepatch version 2.6.24-rc4.
Description:
A security issue has been reported in the Linux Kernel, which can be exploited by malicious, local users to bypass certain security restrictions.
The security issue is caused due to the improper enforcing of the "mmap_min_addr" limit. This can be exploited to allocate pages lower than "mmap_min_addr" by expanding the stack or via "do_brk()" in specially crafted binaries.
It addresses several bugs, at least one of which is a security vulnerability:
Code:
hrtimers: avoid overflow for large relative timeouts (CVE-2007-5966)
patch 62f0f61e6673e67151a7c8c0f9a09c7ea43fe2b5 in mainline
Relative hrtimers with a large timeout value might end up as negative
timer values, when the current time is added in hrtimer_start().
This in turn is causing the clockevents_set_next() function to set an
huge timeout and sleep for quite a long time when we have a clock
source which is capable of long sleeps like HPET. With PIT this almost
goes unnoticed as the maximum delta is ~27ms. The non-hrt/nohz code
sorts this out in the next timer interrupt, so we never noticed that
problem which has been there since the first day of hrtimers.
This bug became more apparent in 2.6.24 which activates HPET on more
hardware.
It solely consists of a patch for a security vulnerability.
Quote:
Use access mode instead of open flags to determine needed permissions (CVE-2008-0001)
patch 974a9f0b47da74e28f68b9c8645c3786aa5ace1a in mainline
Way back when (in commit 834f2a4a1554dc5b2598038b3fe8703defcbe467, aka
"VFS: Allow the filesystem to return a full file pointer on open intent"
to be exact), Trond changed the open logic to keep track of the original
flags to a file open, in order to pass down the the intent of a dentry
lookup to the low-level filesystem.
However, when doing that reorganization, it changed the meaning of
namei_flags, and thus inadvertently changed the test of access mode for
directories (and RO filesystem) to use the wrong flag. So fix those
test back to use access mode ("acc_mode") rather than the open flag
("flag").
Linux Kernel minix File System Denial of Service Vulnerability
Quote:
Description:
A vulnerability has been reported in the Linux Kernel, which can be exploited by malicious, local users to cause a DoS (Denial of Service).
The vulnerability is caused due to improper handling of corrupted data structures in the minix file system. This can be exploited to crash a system by mounting a specially crafted image.
Linux Kernel CHRP Denial of Service Security Issue
Quote:
Description:
A security issue has been reported in the Linux Kernel, which potentially can be exploited by malicious, local users to cause a DoS (Denial of Service).
The security is caused due to a NULL pointer dereference in arch/powerpc/platforms/chrp/setup.c, which can be exploited to crash a vulnerable system.
Successful exploitation requires certain PowerPC hardware.
It includes several bugfixes, including two which address security vulnerabilities.
Quote:
splice: missing user pointer access verification (CVE-2008-0009/10)
patch 8811930dc74a503415b35c4a79d14fb0b408a361 in mainline.
vmsplice_to_user() must always check the user pointer and length
with access_ok() before copying. Likewise, for the slow path of
copy_from_user_mmap_sem() we need to check that we may read from
the user region.
Quote:
vm audit: add VM_DONTEXPAND to mmap for drivers that need it (CVE-2008-0007)
Drivers that register a ->fault handler, but do not range-check the
offset argument, must set VM_DONTEXPAND in the vm_flags in order to
prevent an expanding mremap from overflowing the resource.
I've audited the tree and attempted to fix these problems (usually by
adding VM_DONTEXPAND where it is not obvious).
We have a race between fcntl() and close() that can lead to
dnotify_struct inserted into inode's list *after* the last descriptor
had been gone from current->files.
Since that's the only point where dnotify_struct gets evicted, we are
screwed - it will stick around indefinitely. Even after struct file in
question is gone and freed. Worse, we can trigger send_sigio() on it at
any later point, which allows to send an arbitrary signal to arbitrary
process if we manage to apply enough memory pressure to get the page
that used to host that struct file and fill it with the right pattern...
Quote:
tehuti: move ioctl perm check closer to function start (CVE-2008-1675)
fcntl_setlk()/close() race prevention has a subtle hole - we need to
make sure that if we *do* have an fcntl/close race on SMP box, the
access to descriptor table and inode->i_flock won't get reordered.
As it is, we get STORE inode->i_flock, LOAD descriptor table entry vs.
STORE descriptor table entry, LOAD inode->i_flock with not a single
lock in common on both sides. We do have BKL around the first STORE,
but check in locks_remove_posix() is outside of BKL and for a good
reason - we don't want BKL on common path of close(2).
Solution is to hold ->file_lock around fcheck() in there; that orders
us wrt removal from descriptor table that preceded locks_remove_posix()
on close path and we either come first (in which case eviction will be
handled by the close side) or we'll see the effect of close and do
eviction ourselves. Note that even though it's read-only access,
we do need ->file_lock here - rcu_read_lock() won't be enough to
order the things.
Description:
Some vulnerabilities have been reported in the Linux kernel, which can be exploited by malicious, local users to bypass certain security restrictions and by malicious people to potentially cause a DoS (Denial of Service).
1) An error exists in the implementation of the "sys_utimensat()" system call. This can be exploited to update the access or modification time of arbitrary files via specially crafted arguments passed to the affected system call.
2) A memory leak exists in the "ipip6_rcv()" function included in the IPv6 over IPv4 (SIP) tunneling driver. This can be exploited to potentially exhaust all available memory via specially crafted network packets.
The vulnerabilities are reported in version 2.6.25.2. Prior versions may also be affected.
Linux Kernel "pppol2tp_recvmsg()" Memory Corruption Vulnerability
Quote:
Description:
A vulnerability has been reported in the Linux Kernel, which potentially can be exploited by malicious people to cause a DoS (Denial of Service).
The vulnerability is caused due to a boundary error in the "pppol2tp_recvmsg()" function and can potentially be exploited to corrupt kernel memory via a specially crafted PPP over L2TP packet.
The vulnerability is reported in 2.6.x versions prior to 2.6.26-rc6.
Solution:
Use PPP over L2TP in trusted networks only.
The Linux Kernel is prone to a memory-corruption vulnerability because it fails to properly bounds-check user-supplied input. The issue affects x86_64 ptrace and causes an overflow that subsequently results in the insecure freeing of a structure.
An attacker may exploit this issue to execute arbitrary code with superuser privileges. Successfully exploiting this issue will result in the complete compromise of affected computers. Failed exploit attempts will cause a denial of service.
Versions prior to Linux Kernel 2.6.25.10 are vulnerable.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
