Stack-based buffer overflow in the readarticle function in getarticle.c in newsx 1.6 allows remote attackers to execute arbitrary code via a news article containing a large number of lines starting with a period.

Fedora Repository 3.8.1 allows path traversal when extracting uploaded archives ("Zip Slip"). A remote, authenticated attacker can upload a specially crafted archive that will extract an arbitrary JSP file to a location that can be executed by an unauthenticated GET request. Fedora Repository 3.8.1 was released on 2015-06-11 and is no longer maintained. Migrate to a currently supported version (6.5.1 as of 2025-01-23).

Fedora Repository 3.8.x includes a service account (fedoraIntCallUser) with default credentials and privileges to read read local files by manipulating datastreams. Fedora Repository 3.8.1 was released on 2015-06-11 and is no longer maintained. Migrate to a currently supported version (6.5.1 as of 2025-01-23).

Bottles before 51.0 mishandles YAML load, which allows remote code execution via a crafted file.

Multiple memory leaks in Red Hat Directory Server 7.1 before SP7, Red Hat Directory Server 8, and Fedora Directory Server 1.1.1 and earlier allow remote attackers to cause a denial of service (memory consumption) via vectors involving (1) the authentication / bind phase and (2) anonymous LDAP search requests.

It was discovered that Red Hat Directory Server and Fedora Directory Server is prone to a temporary denial of service attack (high CPU usage) via crafted LDAP search patterns. LDAP search patterns are internally translated to regular expressions. If the regular expression is matched against specially crafted record already stored in the LDAP, it may cause regular expression NFA to iterate over large amount of states, causing one slapd thread to occupy CPU for excessive amount of time.

Additionally, due to a current design of the regular expression handling code, only one slapd thread can execute regular expression NFA code at the time. Because of that, during the processing of such CPU intensive search request, all other search requests using patterns are blocked.

Affected version: Red Hat Directory Server 7.1 and 8 Fedora Directory Server 1.1.1

It was reported that Fedora Atomic updates are trivially vulnerable to a MITM attack.

Upstream fix: https://git.fedorahosted.org/cgit/spin-kickstarts.git/commit/?id=1e408e111008f539c89212a9ca9bb955e2c4f823 Original report: https://bugzilla.redhat.com/showbug.cgi?id=1231287

Richard Megginson discovered a shell command injection flaw in the Admin Server's replication monitor CGI perl script repl-monitor-cgi.pl. Script parameters were not properly sanitized prior to being passed to system() function. An attacker able to access replication monitor CGI script could execute arbitrary shell command with privileges of Admin Server.

Affected versions: - Red Hat Directory Server 7.1 - Admin Server runs with root privileges - Red Hat Directory Server 8 - Admin Server runs under an unprivileged user, following users by default: - nobody on Red Hat Enterprise Linux and Solaris - daemon on HP-UX - Fedora Directory Server - Admin Server runs under an unprivileged user, nobody by default

Description of problem:

Alexei Dobryanov has reported the following kernel utrace related issue (BZ#245735):

1. late ptracemayattach() check

static int ptraceattach(struct taskstruct task) { ... engine = utraceattach(task, (UTRACEATTACHCREATE | UTRACEATTACHEXCLUSIVE | UTRACEATTACHMATCHOPS), &ptraceutraceops, 0); [error checking] if (ptracemayattach(task)) { [more attaching process]

Doing may attach check there is asking for trouble, because utraceattach() will happily create and modify "struct utrace " and create and attach engines to it on task you don't have permissions. Order should be reverted. That's easy.

2. race around &deadengineops setting...

I originally thought #1 would lead to memory leaks, however, written dumb PTRACEATTACH'er gave much more amazing results.

The following program quickly (1 sec) oopses kernel when run against process you normally can't attach to (like normal user to getty processes)

#include <stdlib.h> #include <sys/ptrace.h>

int main(int argc, char argv[]) { pidt pid = atoi(argv[1]);

while (1) ptrace(PTRACEATTACH, pid, NULL, NULL);

return 0; }

Unable to handle kernel NULL pointer dereference at 0000000000000000 RIP: [<0000000000000000>] [<ffffffff8005f1cd>] reportquiescent+0x36/0x154 [<ffffffff8005f316>] utracequiescent+0x2b/0x238 [<ffffffff800601e9>] utracegetsignal+0x45d/0x4c0 [<ffffffff80039c6f>] getsignaltodeliver+0x169/0x47a [<ffffffff80008f5a>] donotifyresume+0xd0/0x7e2 [<ffffffff80203673>] spinunlockirqrestore+0x3f/0x45 [<ffffffff80051d71>] tracehardirqson+0x11b/0x13f [<ffffffff801400c0>] ttyread+0x81/0xc7 [<ffffffff80202ede>] tracehardirqsonthunk+0x35/0x37 [<ffffffff80051d71>] tracehardirqson+0x11b/0x13f [<ffffffff80009b43>] sysretsignal+0x21/0x31 [<ffffffff80009deb>] ptregscallcommon+0x67/0xac

This is a race we chatted with Roland about: http://marc.info/?l=linux-kernel&m=117863520707703&w=2

engine's flags and ops settings in utracedetach() and acting on them in reportquiescent():

utracedetach() reportquiescent() --------------- ------------------ [utrace lock held] [utrace lock is not held]

engine->flags = UTRACEEVENT(QUIESCE) | UTRACEACTIONQUIESCE;

if (engine->flags & UTRACEEVENT(QUIESCE)) REPORT(reportquiesce);

rcuassignpointer(engine->ops, &deadengineops);

At the moment of REPORT call engine's ops are still "live" ptrace ops which do not have ->reportquiesce callback. So, there will oops while calling function at NULL address. "Dead" ptrace engine ops do have dummy callback but it wasn't yet glued.

Obviously, patch #1 won't fix this.

3. Looks like nobody filed double free at utrace aka oops at rcuprocesscallbacks() against RHEL5 kernel.

It's bug https://bugzilla.redhat.com/bugzilla/showbug.cgi?id=207002 against FC6, but, hey, every utrace version has it. Test program attached. Every user can trigger it.

A flaw was found in a Accept Language HTTP header parsers implemented in adminutil library used by various Red Hat Directory Server's Administration Server's CGI scripts. A remote attacker able to connect to Administration Server web interface could cause a CGI scripts to crash, or possibly execute an arbitrary code.

Issue affects: - Red Hat Directory Server 7.1 - adminutil packages shipped in Red Hat Directory Server 8 and Fedora Directory Server, prior to adminutil version 1.1.7

Reported by Michael Simms:

Any user can crash init with a single command

Version-Release number of selected component (if applicable): Fedora 9, patched to latest as of 90 minutes ago

How reproducible: Always. May have to run the command 2-3 times but it always crashes the kernel in the end.

Steps to Reproduce: 1.as ANY user - start a shell 2.gdb anyexecutable 1 3.There will be a kerneloops and usually a kernel crash or hang

Actual results: Kernel blows up

Expected results: Kernel doesnt blow up, permission denied for process init

Additional info:

Quoting the upstream news advisory [1]:

"The 2010.08.05 release comes with a patched config file. With shell code in hyperlinks on a page, one of the sample (uzbl-core) resp. default (uzbl-browser) button bindings (binding for mousebutton2) would execute this code.

Note that just upgrading your uzbl is not enough. If you have an existing config, the change will not be automatically applied. So be sure you have this change in your config."

And an associated bug report [2] exists as well. There is no patch noted in the bug report.

This would affect all versions of Fedora.

[1] http://www.uzbl.org/news.php?id=29 [2] http://www.uzbl.org/bugs/index.php?do=details&taskid=240

The pcs daemon (pcsd) in PCS 0.9.137 and earlier does not set the secure flag for a cookie in an https session, which makes it easier for remote attackers to capture this cookie by intercepting its transmission within an http session. NOTE: this issue was SPLIT per ADT2 due to different vulnerability types. CVE-2015-3983 is for the issue with not setting the HTTPOnly flag.

c-ares is an asynchronous resolver library. When cross-compiling c-ares and using the autotools build system, CARESRANDOMFILE will not be set, as seen when cross compiling aarch64 android. This will downgrade to using rand() as a fallback which could allow an attacker to take advantage of the lack of entropy by not using a CSPRNG. This issue was patched in version 1.19.1.

c-ares is an asynchronous resolver library. When /dev/urandom or RtlGenRandom() are unavailable, c-ares uses rand() to generate random numbers used for DNS query ids. This is not a CSPRNG, and it is also not seeded by srand() so will generate predictable output. Input from the random number generator is fed into a non-compilant RC4 implementation and may not be as strong as the original RC4 implementation. No attempt is made to look for modern OS-provided CSPRNGs like arc4random() that is widely available. This issue has been fixed in version 1.19.1.

aresinetnetpton() is vulnerable to a buffer underflow for certain ipv6 addresses, in particular "0::00:00:00/2" was found to cause an issue. C-ares only uses this function internally for configuration purposes which would require an administrator to configure such an address via aressetsortlist().

CVE-2023-31130. Moderate. Buffer Underwrite in aresinetnetpton() (https://github.com/c-ares/c-ares/security/advisories/GHSA-x6mf-cxr9-8q6v)

A vulnerability was found in the avahi library. This flaw allows an unprivileged user to make a dbus call, causing the avahi daemon to crash.

Impact

Since Requests v2.3.0, Requests has been vulnerable to potentially leaking Proxy-Authorization headers to destination servers, specifically during redirects to an HTTPS origin. This is a product of how rebuildproxies is used to recompute and reattach the Proxy-Authorization header to requests when redirected. Note this behavior has only been observed to affect proxied requests when credentials are supplied in the URL user information component (e.g. https://username:password@proxy:8080).

Current vulnerable behavior(s):

1. HTTP → HTTPS: leak 2. HTTPS → HTTP: no leak 3. HTTPS → HTTPS: leak 4. HTTP → HTTP: no leak

For HTTP connections sent through the proxy, the proxy will identify the header in the request itself and remove it prior to forwarding to the destination server. However when sent over HTTPS, the Proxy-Authorization header must be sent in the CONNECT request as the proxy has no visibility into further tunneled requests. This results in Requests forwarding the header to the destination server unintentionally, allowing a malicious actor to potentially exfiltrate those credentials.

The reason this currently works for HTTPS connections in Requests is the Proxy-Authorization header is also handled by urllib3 with our usage of the ProxyManager in adapters.py with proxymanagerfor. This will compute the required proxy headers in proxyheaders and pass them to the Proxy Manager, avoiding attaching them directly to the Request object. This will be our preferred option going forward for default usage.

Patches Starting in Requests v2.31.0, Requests will no longer attach this header to redirects with an HTTPS destination. This should have no negative impacts on the default behavior of the library as the proxy credentials are already properly being handled by urllib3's ProxyManager.

For users with custom adapters, this may be potentially breaking if you were already working around this behavior. The previous functionality of rebuildproxies doesn't make sense in any case, so we would encourage any users impacted to migrate any handling of Proxy-Authorization directly into their custom adapter.

Workarounds For users who are not able to update Requests immediately, there is one potential workaround.

You may disable redirects by setting allowredirects to False on all calls through Requests top-level APIs. Note that if you're currently relying on redirect behaviors, you will need to capture the 3xx response codes and ensure a new request is made to the redirect destination. import requests r = requests.get('http://github.com/', allowredirects=False)

Credits

This vulnerability was discovered and disclosed by the following individuals.

Dennis Brinkrolf, Haxolot (https://haxolot.com/) Tobias Funke, (tobiasfunke93@gmail.com)

The pcs daemon (pcsd) in PCS 0.9.137 and earlier does not include the HTTPOnly flag in a Set-Cookie header, which makes it easier for remote attackers to obtain potentially sensitive information via script access to this cookie. NOTE: this issue was SPLIT from CVE-2015-1848 per ADT2 due to different vulnerability types.

It was discovered that multiple CGI scripts used by Red Hat / Fedora Directory Server did not properly sanitize %-escaped inputs, resulting in a possibility to conduct cross-site scripting (XSS) attacks.

Issue was caused by a flow in an adminutil library that contain common functionality used by multiple CGI scripts, such as affected GET / POST argument parsing.

Issue is know to affect some Administration Express scripts and Directory Server Gateway (DSGW) scripts.

Affected version: Red Hat Directory Server 7.1 Red Hat Directory Server 8 (flaw limited to Administration Express issues, as DSGW component is not shipped) Fedora Directory Server

The Fedora Secure Boot CA certificate shipped with shim in Fedora was expired which could lead to old or invalid signed boot components being loaded.

Currently, the fields in the query string are not sanitized for special characters in Fedora Koji

The Linux Kernel lockdown mode for kernel versions starting on 6.12 and above for Fedora Linux has the lockdown mode disabled without any warning. This may allow an attacker to gain access to sensitive information such kernel memory mappings, I/O ports, BPF and kprobes. Additionally unsigned modules can be loaded, leading to execution of untrusted code breaking breaking any Secure Boot protection. This vulnerability affects only Fedora Linux.

opencryptoki, when compiled with -DSPINXPL (as it is in Red Hat Enterprise Linux and Fedora), creates certain dot files in the /tmp directory, such as .pkapixpk and .pkcs11spinloc. These are not temporary files and are rather used for locking purposes. They are created in a way that allows symlink attacks.

As files are opened RDWR, and not written to, they don't seem to allow file corruption as typical symlink attacks do. It is still possible to create new files at arbitrary locations (e.g. /etc/nologin) or make arbitrary file world writable (e.g. /etc/shadow) with the privileges of the user running pkcsslotd or an application using opencrpytoki library. Attacker does not need to be a member of the pkcs11 group, though symlinks would usually need to be created before the first use of the opencryptoki on the system.

A symbol clash issue was found in the pamsshagentauth PAM module as shipped with Red Hat Enterprise Linux 6 and Fedora. In case of certain errors, pamsshagentauth calls error() function to report problems. Due to the way pamsshagentauth was built in Red Hat Enterprise Linux and Fedora packages, this led to glibc's error() function being called instead of the error() function from OpenSSH sources that was meant to be used. As the two error functions expect different arguments, this could cause an application configured to use the pamsshagentauth module (typically su or sudo) to crash, disclose portion of its memory, or, possibly, execute arbitrary code.

This issue did not affect upstream versions of pamsshagentauth and was specific to Red Hat Enterprise Linux / Fedora packages, where pamsshagentauth is part of the openssh source RPM. This bundling is used to avoid duplicating OpenSSH source code. pamsshagentauth embeds a copy of the OpenSSH code. It is not used in Red Hat Enterprise Linux / Fedora packages, instead OpenSSH code from the OpenSSH build is used. This flaw was consequence of this way the PAM module is built.

Several people reported the oops: "kernel BUG at kernel/timer.c:729!" and the stack trace is:

#7 [ffff880214d25c10] modtimer+501 at ffffffff8106d905 #8 [ffff880214d25c50] brmulticastdelpg.isra.20+261 at ffffffffa0731d25 [bridge] #9 [ffff880214d25c80] brmulticastdisableport+88 at ffffffffa0732948 [bridge] #10 [ffff880214d25cb0] brstpdisableport+154 at ffffffffa072bcca [bridge] #11 [ffff880214d25ce8] brdeviceevent+520 at ffffffffa072a4e8 [bridge] #12 [ffff880214d25d18] notifiercallchain+76 at ffffffff8164aafc #13 [ffff880214d25d50] rawnotifiercallchain+22 at ffffffff810858f6 #14 [ffff880214d25d60] callnetdevicenotifiers+45 at ffffffff81536aad #15 [ffff880214d25d80] devclosemany+183 at ffffffff81536d17 #16 [ffff880214d25dc0] rollbackregisteredmany+168 at ffffffff81537f68 #17 [ffff880214d25de8] rollbackregistered+49 at ffffffff81538101 #18 [ffff880214d25e10] unregisternetdevicequeue+72 at ffffffff815390d8 #19 [ffff880214d25e30] tundetach+272 at ffffffffa074c2f0 [tun] #20 [ffff880214d25e88] tunchrclose+45 at ffffffffa074c4bd [tun] #21 [ffff880214d25ea8] fput+225 at ffffffff8119b1f1 #22 [ffff880214d25ef0] fput+14 at ffffffff8119b3fe #23 [ffff880214d25f00] taskworkrun+159 at ffffffff8107cf7f #24 [ffff880214d25f30] donotifyresume+97 at ffffffff810139e1 #25 [ffff880214d25f50] intsignal+18 at ffffffff8164f292

The bug was usually hit when shutting down a KVM guest.

Upstream fix: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c7e8e8a8f7a70b343ca1e0f90a31e35ab2d16de1

Introduced by: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9f00b2e7cf241fa389733d41b6

Introduced in upstream version: v3.11-rc1 (but we had it in Fedora because of bz#880035)

References: host multicast triggers oops" href="showbug.cgi?id=980254">https://bugzilla.redhat.com/showbug.cgi?id=980254 http://pkgs.fedoraproject.org/cgit/kernel.git/commit/?h=f19&id=a993279a9bb538ae524fca69ec23c5c1b428f47e

Fedora 18 is found to be vulnerable to the blind command execution on the lock screen, and Fedora 19 is found to execute command through "Enter the Command" dialog box at the lock screen.

The issue is that in Fedora 18, when you open either the Activities panel or "Enter a command" dialog box (Alt+F2), and then lock the screen or let the screensaver lock the screen, then if you start typing on the lock screen, instead of entering the password or just waking the screen, it actually types anything you type on the Activities panel or "Enter a command" dialog box, so anyone who enters a executable command and press enter, the command is executed even when the screen is locked.

In Fedora 19, the "Enter the Command" dialog box is visible even after you lock the screen, so anyone can write the commands in the box and execute them over a locked screen.

The issue is still to be fixed and tested on Gnome Fedora 18 and 19 machines. KDE version were not found to be affected.

When rebasing pure-ftpd in Fedora 26, 27 and Rawhide, a packaging error occurred due to which the original configuration was ignored after update and service started running with default configuration. This has security implications because of overriding security-related configuration as well.

This issue is Fedora-specific and affected Fedora 26, 27 and Rawhide. The affected downstream version is pure-ftpd-1.0.46-1.

dnsmasq, as shipped with Fedora and Red Hat Enterprise Linux, has a default configuration that makes it listen on any interface and accept queries from addresses outside of its local subnet. In particular, the option local-service is not enabled. Users that enable dnsmasq on their system with its default configuration may inadvertently make it an open resolver accessible from any address on the internet, potentially being involved in Distributed Denial of Service (DDoS) attacks against a victim.

Richard Megginson discovered that Admin Server as used by Red Hat Directory Server 8 and Fedora Directory Server does not properly restrict access to CGI scripts. This could allow unauthenticated user to get access to information or perform tasks that should be restricted to authenticated administrative users.