security [ARCHIVED]

security@lists.fedoraproject.org

840 discussions

Introduction - Security Team
by Marcelo Piedra 24 Feb '21

24 Feb '21

Hello, I would like to join the Security Team and the Apprenticeship. My name is Marcelo Piedra. FAS ID: stonefeller. My main interest is Cybersecurity, and specifically I am interestested in network, password, server and services security. I want to join to learn more, contribute to open source to gain hands-on experience and get more involved with time. Please find attached the key. All the best, Marcelo

1 0

Re: Preparing openvpn3 packaging for review - openssl challenges
by Tomas Mraz 19 Feb '20

19 Feb '20

On Wed, 2020-02-19 at 11:06 +0100, David Sommerseth wrote: > On 19/02/2020 08:25, Tomas Mraz wrote: > [...snip...] > > > if (!SSL_CTX_set_cipher_list(ctx, > > > /* default list as a > > > basis > > > */ > > > "DEFAULT" > > > /* Disable export > > > ciphers, > > > low and medium */ > > > ":!EXP:!LOW:!MEDIUM" > > > /* Disable static > > > (EC)DH > > > keys (no forward secrecy) */ > > > ":!kDH:!kECDH" > > > /* Disable DSA private > > > keys */ > > > ":!DSS" > > > /* Disable RC4 cipher > > > */ > > > ":!RC4" > > > /* Disable MD5 */ > > > ":!MD5" > > > /* Disable unsupported > > > TLS > > > modes */ > > > ":!PSK:!SRP:!kRSA" > > > /* Disable SSLv2 > > > cipher > > > suites*/ > > > ":!SSLv2" > > > )) > > > OPENVPN_THROW(ssl_context_error, > > > "OpenSSLContext: > > [...snip...] > > > > The second block should really be fine too, it just strictly > > > enforces > > > a fairly > > > strict default set of ciphers. > > > > No, the second call is not correct. Basically there should be no > > call > > to SSL_CTX_set_cipher_list() unless the user explicitly wants to > > override the defaults. The default in Fedora is already sane and > > safe > > and ensures the crypto policy is properly applied. > > I brought your argument up internally, and added Arne Schwabe on Cc > as he > knows both OpenVPN and OpenSSL and how they integrate even better. > > We understand and agree that the system running OpenVPN should be > able to > define the defaults and avoid hard-coding it. But we explicitly want > to > remove any non-PFS compliant ciphers (like kDH, kECDH, kRSA), which > in most > cases makes the setup stricter than the system > configuration. Currently we > see that Fedora's default ciphers allow some non-DH/ECDH and non-PFS > capable > ciphers. > > Another aspect is that since OpenVPN is talking strictly to other > OpenVPN > capable products (where SoftEther is the only product we're aware of > not being > under the fold of OpenVPN Inc or the OpenVPN community). This > results in > OpenVPN being able to further reduce the available ciphers further > than the > more standard TLS defaults, thus increasing the security level of the > TLS > channel for the VPN tunnel. > > At the same time we also see the argument where someone wants an even > stricter > set of ciphers. In OpenVPN 2, we have that capability via --tls- > cipher and > --tls-ciphersuites (for TLSv1.3). I do see that OpenVPN 3 lacks > these > options, but that is something we are looking into. This would not be an issue if these options are used only when user explicitly configures them. > If there is a better way to narrow down the list of ciphers we allow > in > OpenVPN instead of replacing the cipher list, that would be even > better from > our point of view. We are really reluctant to implicitly open up for > ciphers > which reduces the security level of OpenVPN, where PFS ability is a > critical > part of the ciphers being used. You can use "PROFILE=SYSTEM" instead of "DEFAULT" as a start. However this special string is downstream-only. -- Tomáš Mráz No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.]

2 2

Preparing openvpn3 packaging for review - openssl challenges
by David Sommerseth 19 Feb '20

19 Feb '20

Hi, I'm running rpmlint against packages built based on the Fedora Copr [1] build I've provided for some time. I'm planning to move this forward for the standard Fedora and EPEL repositories. But rpmlint complains about the usage of SSL_CTX_set_cipher_list(), which I in this case would call a false-positive for OpenVPN. [1] <https://copr.fedorainfracloud.org/coprs/dsommers/openvpn3/> <https://gitlab.com/dazo/copr-openvpn3> The code which trips this warning is: ------------------------------------------------------------------------------- if (config->force_aes_cbc_ciphersuites) { if (!SSL_CTX_set_cipher_list(ctx, "DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA")) OPENVPN_THROW(ssl_context_error, "OpenSSLContext: SSL_CTX_set_cipher_list failed for force_aes_cbc_ciphersuites"); } else { if (!SSL_CTX_set_cipher_list(ctx, /* default list as a basis */ "DEFAULT" /* Disable export ciphers, low and medium */ ":!EXP:!LOW:!MEDIUM" /* Disable static (EC)DH keys (no forward secrecy) */ ":!kDH:!kECDH" /* Disable DSA private keys */ ":!DSS" /* Disable RC4 cipher */ ":!RC4" /* Disable MD5 */ ":!MD5" /* Disable unsupported TLS modes */ ":!PSK:!SRP:!kRSA" /* Disable SSLv2 cipher suites*/ ":!SSLv2" )) OPENVPN_THROW(ssl_context_error, "OpenSSLContext: SSL_CTX_set_cipher_list failed"); #if OPENSSL_VERSION_NUMBER >= 0x10002000L && OPENSSL_VERSION_NUMBER < 0x10100000L SSL_CTX_set_ecdh_auto(ctx, 1); // this method becomes a no-op in OpenSSL 1.1 #endif } ------------------------------------------------------------------------------- These calls can be found in openvpn/openssl/ssl/sslctx.hpp <https://github.com/OpenVPN/openvpn3/blob/b62654274fd938ebb82dbe3a2e78d9b8fd…> The first SSL_CTX_set_cipher_list() is being slate for removal, as the "force_aes_cbc_ciphersuits" feature is not considered needed any more; negotiation works much better nowadays than when this was added about 5 years ago. But the cipher-list here shouldn't be of that much concern. The second block should really be fine too, it just strictly enforces a fairly strict default set of ciphers. So my question is if this will be a show-stopper for getting the openvpn3 package into the standard Fedora + EPEL repositories? -- kind regards, David Sommerseth OpenVPN Inc

2 1

Remove QtWebKit4
by Christian Stadelmann 22 Jun '19

22 Jun '19

qtwebkit (Qt4's WebKit binding) is full of hundreds of known CVEs and hasn't seen a security patch in years. For the same reason, WebKitGtk has been removed from Fedora [1]. How about a plan to do the same with qtwebkit? I've already opened a bug report against qtwebkit [2] but it does not seem to have any effect. [1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org… [2] https://bugzilla.redhat.com/show_bug.cgi?id=1711519

1 0

sshd PermitRootLogin yes, security impact
by Chris Murphy 16 Apr '19

16 Apr '19

Hi, Fedora Final release criterion says: The release must contain no known security bugs of 'important' or higher impact according to the Red Hat severity classification scale which cannot be satisfactorily resolved by a package update (e.g. issues during installation). I've discovered this bug from jjelen https://bugzilla.redhat.com/show_bug.cgi?id=89216 The gist is that Fedora uses a (silently) modified sshd_config from openssh upstream, which sets `PermitRootLogin yes` instead of the upstream default of `prohibit-password` and this sounds like it would be an important or higher impact security impact leaving it set to yes. Could someone reply here or in the bug with such an assessment? Thanks! -- Chris Murphy

2 1

Enforcing system crypto policies
by Frank Ueberschar 05 Apr '19

05 Apr '19

Here https://docs.fedoraproject.org/en-US/packaging-guidelines/CryptoPolicies/ is a proposal to use a specific cipher list string for SSL_CTX_set_cipher_list(): "PROFILE=SYSTEM". Especially this citation: "if that call is present and provided a fixed string which does not contain PSK or SRP, replace the string with "PROFILE=SYSTEM", or remove the call" We have to rely on PSK. What ist the reason behind the above advice? Thanks, Frank

3 2

Introduction
by Antonette Caldwell 22 Feb '19

22 Feb '19

I will introduce myself. My name is Antonette, as you can see my fsa id is acaldwell. I have been working with a company as a tech support for almost 1 and a half. I was introduced to Fedora back in 2014, and I've been doing (on and off) web development since 2015. I become pretty interested in the security world, and was hoping for my foot in the door into a cyber security analyst type position. I am working toward a couple of certificates, such as security plus (which I have heard is useless in some places), and the SANS certifications as well. I posted earlier in the Spins mailing lists, so I was given useful links to start with. Thank you for taking the time to read my inquires and my introduction.

2 1

assessment for GNOME dialog asking for user passphrase
by Chris Murphy 11 Sep '18

11 Sep '18

Hi, I've filed a gnome-shell bug (see link below) for a change in modal dialog I see when connecting to an ssh server using public key authentication. The Fedora 28 dialog shows the key name, the Fedora 29 dialog is generic, I can only guess by time proximity what I'm entering the passphrase for. Question is whether this constitutions an "important" security bug or higher. The bug has screenshots for both the F28 and F29 dialogs in question. generic modal dialog asking for passphrase is presented when using ssh with public key https://bugzilla.redhat.com/show_bug.cgi?id=1627952 Fedora's release blocking security criterion for final reads in part: "release must contain no known security bugs of 'important' or higher" https://fedoraproject.org/wiki/Fedora_29_Final_Release_Criteria#Security_bu… Red Hat severity classification scale https://access.redhat.com/security/updates/classification/ -- Chris Murphy

2 1

[Fedocal] Reminder meeting : Hope XII
by jasoncallaway＠fedoraproject.org 12 Jul '18

12 Jul '18

Dear all, You are kindly invited to the meeting: Hope XII on 2018-07-20 from 00:00:00 to 00:00:00 UTC At Hotel Pennsylvania, 401 7th Ave, New York, NY 10001 The meeting will be about: Join the Fedora Red Team at HOPE XII More information available at: [http://xii.hope.net](http://xii.hope.net) Source: https://apps.fedoraproject.org/calendar/meeting/6955/

1 0

[Fedocal] Reminder meeting : Kubernetes hack session
by jasoncallaway＠fedoraproject.org 09 Apr '18

09 Apr '18

Dear all, You are kindly invited to the meeting: Kubernetes hack session on 2018-04-11 from 10:00:00 to 16:00:00 US/Eastern At https://meet.google.com/adc-xwet-wir The meeting will be about: Join the Fedora Red Team at https://meet.google.com/adc-xwet-wir for a hack / learning session on Kubernetes security topics Source: https://apps.fedoraproject.org/calendar/meeting/8777/

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

security [ARCHIVED]