A vulnerability was found in kexec, allowing the attacker to bypass the security mechanism of securelevel/secureboot combination.
When the kernel was booted with UEFI Secure Boot enabled, securelevel is set. If kexec (either through crash or admin action) is then used to load the same kernel, after reboot securelevel is disabled. In this state, the system is missing the protections provided by securelevel, for example kexec may be used to load an unsigned kernel via the legacy system call kexecload. In the securelevel patchset, the state of UEFI Secure Boot is queried in the EFI stub, and sets a bootparams flag to indicate the state of UEFI Secure Boot. This flag is then used in setuparch() to determine the correct state of securelevel. If the kernel is not booted via the EFI stub, securelevel is not set even if UEFI Secure Boot is enabled.
Patch can be found in product bug:
https://bugzilla.redhat.com/showbug.cgi?id=1243998#c3
Upstream patch:
https://github.com/mjg59/linux/commit/4b2b64d5a6ebc84214755ebccd599baef7c1b798
CVE assignment:
http://seclists.org/oss-sec/2015/q4/85
Kernel panic (via skboverpanic) is encountered when sctp stack receive a malformed asconf chunks.
skboverpanic: text:ffffffffa01ea1c3 len:31056 put:30768 head:ffff88011bd81800 data:ffff88011bd81800 tail:0x7950 end:0x440 dev:<NULL> ------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:129! [...] Call Trace: <IRQ> [<ffffffff8144fb1c>] skbput+0x5c/0x70 [<ffffffffa01ea1c3>] sctpaddtochunk+0x63/0xd0 [sctp] [<ffffffffa01eadaf>] sctpprocessasconf+0x1af/0x540 [sctp] [<ffffffff8152d025>] ? readunlockbh+0x15/0x20 [<ffffffffa01e0038>] sctpsfdoasconf+0x168/0x240 [sctp] ...
A remote attacker could use this flaw to crash the system.
Acknowledgements:
This issue was discovered by Liu Wei of Red Hat.
Kernel panic is encountered when sctp stack receives duplicate asconf chunks.
Upstream commmit:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b69040d8e39f20d5215a03502a8e8b4c6ab78395
Last updated 24 July 2024
A flaw was found where a regular user could remove xattr permissions on files by using the chown or write systemcalls. An attacker could use this feature to remove capabilities effectively denying elevated permissions to valid users. Certain services and applications require the capabilities subsystem to work correctly.
Discussed here:
https://lkml.org/lkml/2015/1/17/145
As of 3.19 release, this commit is NOT in mainline tree.
A local user can trigger a flaw in the Linux kernel's handling of key lookups in the keychain subsystem.
The keyrejectandlink() function contains an error in which a key-lookup can fail and in an attempt to cache the failed lookup may attempt to free memory which can still be in use.
This could crash the system or at worse free a memory block which would then be re-used by another kernel mechanism causing a user after free.
Product bug:
https://bugzilla.redhat.com/showbug.cgi?id=1341352
Upstream patch:
https://www.spinics.net/lists/linux-kernel-janitors/msg26069.html
IPv6 fragment identification generation is way beyond what we use for IPv4 : It uses a single generator. Its not scalable and allows DOS attacks.
Now inetpeer is IPv6 aware, we can use it to provide a more secure and scalable frag ident generator (per destination, instead of system wide)
This patch : 1) defines a new secureipv6id() helper 2) extends inetgetid() to provide 32bit results 3) extends ipv6selectident() with a new dest parameter
http://thread.gmane.org/gmane.linux.network/201773
Acknowledgements:
Red Hat would like to thank Fernando Gont for reporting this issue.
Last updated 24 July 2024
A flaw was found in the way ansi cprng implementation in the Linux kernel processed non-block size aligned requests. If several small requests are made that are less than the instances block size, the remainder for loop code doesn't increment randdatavalid in the last iteration, meaning that the last bytes in the randdata buffer gets reused on the subsequent smaller-than-a-block request for random data.
Acknowledgements:
Red Hat would like to thank Stephan Mueller for reporting this issue.
Buffer overflow in the VFAT filesystem implementation in the Linux kernel before 3.3 allows local users to gain privileges or cause a denial of service (system crash) via a VFAT write operation on a filesystem with the utf8 mount option, which is not properly handled during UTF-8 to UTF-16 conversion.
Last updated 24 July 2024
Last updated 24 July 2024
Last updated 24 July 2024
Last updated 24 July 2024
An excessive resource consumption flaw was found in the way the Linux kernel's networking subsystem processed TCP Selective Acknowledgment (SACK) segments. While processing SACK segments, the Linux kernel's socket buffer (SKB) data structure becomes fragmented, which leads to increased resource utilization to traverse and process these fragments as further SACK segments are received on the same TCP connection. A remote attacker could use this flaw to cause a denial of service (DoS) by sending a crafted sequence of SACK segments on a TCP connection.
It was reported [1] that Apache QPID would crash when receiving data from a client that is not valid AMQP data, resulting in a shut down of the cluster rather than the client being disconnected. This was corrected upstream by r785788 [2].
[1] https://bugzilla.redhat.com/showbug.cgi?id=506580 [2] http://svn.apache.org/viewvc?revision=785788&view=revision
It was reported [1], [2] that Apache QPID would crash due to a NULL pointer dereference when a remote, authenticated user attempted to redeclare an existing exchange and add a new alternate exchange. This would result in a denial of service condition of the server. This was corrected upstream by r811188 [3].
[1] https://issues.apache.org/jira/browse/QPID-2080 [2] https://bugzilla.redhat.com/showbug.cgi?id=517751 [3] http://svn.apache.org/viewvc?revision=811188&view=revision
Condor 6.5.4 through 7.2.4, 7.3.x, and 7.4.0, as used in MRG, Grid for MRG, and Grid Execute Node for MRG, allows remote authenticated users to queue jobs as an arbitrary user, and thereby gain privileges, by using a Condor command-line tool to modify an unspecified job attribute.
Multiple format string flaws were found in Condor:
a) when the XML message log format was requested in Condor submit job by remote Condor user and that user attempted to write a specially-crafted message into user log file via condorhold tool it could lead to condorschedd daemon crash, or, potentially arbitrary code execution with the privileges of the 'condor' user []. Also this way an attacker could potentially prevent other Condor jobs from being scheduled and ever executed,
b) request for file transfer by remote Condor user to transmit a file, with specially-crafted name, could lead to child process of condorschedd daemon to crash (repeated process, where condorschedd daemon would fork a child process to handle the request, the child to crash, while trying to handle it and condorschedd daemon to fork another child since the particular Condor job still have not been completed successfully).
Upstream bug report (mentioning only one attack vector): [1] https://condor-wiki.cs.wisc.edu/index.cgi/tktview?tn=2660
General upstream patch (addressing among these flaws also couple of compiler warning problems): [2] http://condor-git.cs.wisc.edu/?p=condor.git;a=commitdiff;h=5e5571d1a431eb3c61977b6dd6ec90186ef79867
-- [] Arbitrary code execution was possible only on systems, where Condor daemons were not compiled with FORTIFYSOURCE protection mechanism. On systems with this protection enabled, particular flaw would lead to Condor service crash only.
A flaw was discovered in cumin where it would log broker authentication credentials to the cumin log file. A local user exploiting this flaw could connect to the broker outside of cumin's control and perform certain operations such as scheduling jobs, setting attributes on jobs, as well as holding, releasing or removing jobs. The user could also use this to, depending on the defined ACLs of the broker, manipulate message queues and other privileged operations.
It was found that vsftpd, Very Secure FTP daemon, when the network namespace (CONFIGNETNS) support was activated in the kernel, used to create a new network namespace per connection. A remote attacker could use this flaw to cause memory pressure (kernel OOM killer protection mechanism to be activated and potentially terminate vsftpd or arbitrary [vsftpd independent] process, which satisfied the OOM killer process selection algorithm).
References: [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=629373 [2] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/720095
Public PoC (from [2]): ======================
The test is started in this way:
$ for i in 1 2 3 4 5 6 7 8 ; do ./feedftp $i >/dev/null & done
What is observed during the test is that /proc/vmallocinfo grows continually with lines like the following being added:
0xffffe8ffff800000-0xffffe8ffffa00000 2097152 pcpugetvmareas+0x0/0x790 vmalloc 0xffffe8ffffa00000-0xffffe8ffffc00000 2097152 pcpugetvmareas+0x0/0x790 vmalloc 0xffffe8ffffc00000-0xffffe8ffffe00000 2097152 pcpugetvmareas+0x0/0x790 vmalloc
vsftpd bug: https://bugzilla.redhat.com/showbug.cgi?id=711134
Proposed patches (but has connection rates problem): http://patchwork.ozlabs.org/patch/88217/
An XML eXternal Entity (XXE) flaw was found in Nokogiri, a Ruby gem for parsing HTML, XML, and SAX. Using external XML entities, a remote attacker could specify a URL in a specially crafted XML that, when parsed, would cause a connection to that URL to be opened.
A patch shipped with the 1.5.4 release of Nokogiri provided a "nonet" option to disable external connections. However, local file URLs could still be used to exploit this flaw. The 1.6.4 release of Nokogiri fixed this issue by using libxml2 2.9.0.
Additional information is detailed at:
https://github.com/sparklemotion/nokogiri/issues/693#issuecomment-68334768
CVE request and assignment:
http://seclists.org/oss-sec/2015/q1/57
Cross-site scripting (XSS) vulnerability in the web interface for cumin in Red Hat Enterprise MRG Grid 2.4 allows remote attackers to inject arbitrary web script or HTML via the "Max allowance" field in the "Set limit" form.
A flaw was found in the way cumin parsed POST request data. A remote attacker could potentially use this flaw to perform SQL injection attacks on cumin's database.
cumin in Red Hat Enterprise MRG Grid 2.4 does not properly enforce user roles, which allows remote authenticated users to bypass intended role restrictions and obtain sensitive information or perform privileged operations via unspecified vectors.
Multiple cross-site request forgery (CSRF) vulnerabilities in the web interface for cumin in Red Hat Enterprise MRG Grid 2.4 allow remote attackers to hijack the authentication of cumin users for unspecified requests.
A denial of service flaw was found in the way Condor's policy definition evaluator processed certain policy definitions. If an administrator used an attribute defined on a job in any of the following condorstartd policies (CONTINUE, KILL, PREEMPT, SUSPEND), a remote Condor service user could use this flaw to cause a denial of the condorstartd service by submitting a Condor job that caused certain policy definition to be evaluated to either ERROR or UNDEFINED states.
Workaround: =========== Check for UNDEFINED & ERROR in the policy configuration.
Cumin, as used in Red Hat Enterprise MRG 2.4, allows remote attackers to cause a denial of service (CPU and memory consumption) via a crafted Ajax update request.
Linux kernel built with an Ext4 file system is vulnerable to a system hang situation when [auto]mounting a non-journal filesystem with an orphan list to clear.
A user could use this flaw to stall the system resulting in DoS.
Upstream fix: ------------- -> https://git.kernel.org/linus/0e9a9a1ad619e7e987815d20262d36a2f95717ca
MongoDB before 2.0.9 and 2.2.x before 2.2.4 does not properly validate requests to the nativeHelper function in SpiderMonkey, which allows remote authenticated users to cause a denial of service (invalid memory access and server crash) or execute arbitrary code via a crafted memory address in the first argument.