Hi Neil, On 6. Aug 2024, at 11:02, Neil Horman <nhorman () openssl org> wrote:

1) Are distributions/users comfortable with this approach in the time frame proposed? I don’t think this will be a problem for Fedora, CentOS Stream, and RHEL. They mostly disable TLS <1.2 without a simple way to bring it back already. 2) Would builders of OpenSSL consider using the default configuration (with TLS1.0/1.1 disabled in 4.0), or would they ship with these protocols re-enabled in their builds? I would strongly argue for keeping those disabled in Fedora. It’s already not simple to re-enabled them in CentOS Stream or RHEL. 3) If the deprecated protocols are re-enabled, what would constitute a reasonable warning mechanism to inform users that these protocols are going away at some point in the future to pressure users to update to a newer, more secure protocol? I believe the best you can do as a library is what you are already doing: Disabling by default, and possibly marking any TLS-1.0/1.1-specific APIs deprecated.

Logging to stderr from a library is out of the question. Logging to syslog can fail due to SELinux on distros that have it.

The only other good solution we’ve come up with is to add a USDT probe point to deprecated code paths and provide a utility for users to run on their system that will highlight any use of these code paths. That’s Linux-specific, and most users won’t run such a tool, though.

HTH, Clemens

-- Clemens Lang RHEL Crypto Team Red Hat

On Tue, Oct 03, 2023 at 05:50:36PM +0000, Qualys Security Advisory wrote: We successfully exploited this vulnerability and obtained full root privileges on the default installations of Fedora 37 and 38, Ubuntu 22.04 and 23.04, Debian 12 and 13; other distributions are probably also vulnerable and exploitable (one notable exception is Alpine Linux, which uses musl libc, not the glibc). We will not publish our exploit for now; however, this buffer overflow is easily exploitable (by transforming it into a data-only attack), and other researchers might publish working exploits shortly after this coordinated disclosure. And they did, here are a couple:

https://github.com/leesh3288/CVE-2023-4911 https://github.com/RickdeJager/CVE-2023-4911

Alexander

Hello All,

Tavis Ormandy reported a flaw in grub2-set-bootflag utility of grub2.

grub-set-bootflag is a command line to set bootflags in GRUB's stored environment. This is a downstream utility which is shipped with Red Hat Enterprise Linux 8 and Fedora. A flaw was found in this application which would could allow a local attacker (someone having a local account on the system) to cause grub configuration files to be truncated. Whenever the machine was rebooted, grub would fail to read the configuration files and the system would be rendered unbootable.

More details and patches available in: https://bugzilla.redhat.com/showbug.cgi?id=1764925

-- Huzaifa Sidhpurwala / Red Hat Product Security

It was found that default configuration for nagios on Fedora is administrative account with user "nagiosadmin" with fixed password "nagiosadmin" and no IP based access restriction. This information is missing in packaged README file.

Original report:

https://bugzilla.redhat.com/showbug.cgi?id=1295155

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.

A security flaw was found in the way init script implementation of the Tomcat service, an Apache Servlet/JSP Engine, as used in various versions of Red Hat Enterprise Linux and Fedora, performed management of Tomcat log file. A local attacker could use this flaw to cause denial of service or, potentially, execute arbitrary code with the privileges of the privileged system user (root) via symbolic link attacks on Tomcat log file.

Acknowledgements:

Red Hat would like to thank Simon Fayer of Imperial College London for reporting this issue.

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:

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.