security March 2014

security@lists.fedoraproject.org

8 participants
9 discussions

available crypto policies
by Nikos Mavrogiannopoulos 06 Jun '14

06 Jun '14

Hello, For the purposes of the Crypto Policies change proposal [0], I think I've settled to the following three policy levels (inspired by the ENISA levels but with a rename of the good LEGACY level to DEFAULT). Any comments or suggestions are appreciated. As these levels will be a moving target across releases (will provide defaults that reflect the current state of the art), levels of previous fedora releases will be referenced as LEVELNAME-F21. [0]. https://fedoraproject.org/wiki/Changes/CryptoPolicy regards, Nikos The levels and their current settings: =====LEGACY===== A level that may include algorithms with known weaknesses (but not completely broken) which will ensure maximum compatibility with legacy systems. It should provide at least 64-bit security and include RC4, but not MD5 as signature algorithm. MACs: MD5, SHA1+ Curves: All supported Signature algorithms: must use SHA-1 hash or better Ciphers: AES-GCM, AES-CBC, CAMELLIA-GCM, CAMELLIA-CBC, 3DES-CBC, RC4 Key exchange: ECDHE, RSA, DHE DH params size: 768+ RSA params size: 768+ SSL Protocols: All supported (SSL3.0+) =====DEFAULT====== A reasonable default for today's standards. For F21 it should provide 80-bit security and no broken ciphers like RC4. MACs: SHA1+ Curves: All supported Signature algorithms: must use SHA-1 hash or better Ciphers: AES-GCM, AES-CBC, CAMELLIA-GCM, CAMELLIA-CBC, 3DES-CBC Key exchange: ECDHE, RSA, DHE DH params size: 1024+ RSA params size: 1024+ SSL Protocols: All supported (SSL3.0+) =====FUTURE====== A level that will provide security on a conservative level that is believed to withstand any near-term future attacks. That will be an 128-bit security level, without including protocols with known attacks available (e.g. SSL 3.0/TLS 1.0). This level may prevent communication with commonly used systems that provide weaker security levels (e.g., systems that use SHA-1 as signature algorithm). MACs: SHA1+ Curves: All supported Signature algorithms: must use SHA-256 hash or better Ciphers: AES-GCM, AES-CBC, CAMELLIA-GCM, CAMELLIA-CBC Key exchange: ECDHE, RSA, DHE DH params size: 2048+ RSA params size: 2048+ SSL Protocols: TLS1.1+

12 52

Crypto guidelines for Fedora
by Till Maas 03 Apr '14

03 Apr '14

Hi, I recently noticed that several packages in Fedora create RSA keys with inappropriate key sizes: dnssec-trigger creates RSA 1536 keys with certificate that is valid for 20 years: https://bugzilla.redhat.com/show_bug.cgi?id=1045689 dropbear-keygen creates by default RSA 1024 keys: https://bugzilla.redhat.com/show_bug.cgi?id=1039311 Some other observations: ssh-keygen on F19 creates RSA 2048 keys by default ENISA recommends to at least RSA 3072 keys: http://www.enisa.europa.eu/activities/identity-and-trust/library/deliverabl… If e.g. AES-256 is used. RSA 15360 is recommended for long-term usage. Therefore I would like to propose a packaging guideline about which minimum key size software in Fedora should generate by default. It seems to me that requiring RSA 3072 key by default in Fedora is a good initial compromise. I did not notice RSA keys with more than 4096 bits regularly, therefore I am not sure whether using RSA 15360 keys by default is a good idea. What is your opinion? Regards Till

6 12

Enable GCC hardening by default
by Florian Weimer 31 Mar '14

31 Mar '14

This was briefly discussed over on debian-devel. Would this something Fedora might want to do, too? -------- Original Message -------- Subject: Re: Bits from the Security Team Resent-Date: Sat, 08 Mar 2014 18:24:06 +0100 Resent-From: Florian Weimer <fw(a)deneb.enyo.de> Resent-To: fweimer(a)redhat.com Date: Fri, 7 Mar 2014 10:42:12 +0100 From: Moritz Muehlenhoff <jmm(a)inutil.org> To: Matthias Klose <doko(a)debian.org> CC: Paul Wise <pabs(a)debian.org>, debian-devel(a)lists.debian.org, security(a)debian.org On Thu, Mar 06, 2014 at 05:33:42AM +0100, Matthias Klose wrote: > Am 06.03.2014 02:00, schrieb Paul Wise: > >> * The distribution hardening using dpkg-buildflags is coming along > >> nicely. > > > > Unfortunately this doesn't apply to binaries compiled outside of the > > package building system. It would be great if we could adopt the > > Ubuntu approach of just enabling the flags in GCC itself. Even better > > would be to get GCC upstream to finally enable them by default. > > This should not be enabled in the distro itself, and if, then not before it can > be enabled upstream. From my point of view it was a mistake to enable it this > way before getting this upstream. However it is a lot of work to get the > compiler to build itself with these flags and the testsuite produce the same > results as without these. In the past neither the Ubuntu security team nor the > Google ChromeOS team had time and resources to bring these patches upstream. I agree we should stick with dpkg-buildflags until this is fixed upstream. Gentoo Hardened tried to upstream this a year ago, but apparently this didn't make the cut yet: http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00473.html As for the GSoC project; GCC partiticates, if anyone wants to push this, I suggest to talk to GCC developers and see whether there's a mentor available. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-devel-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: https://lists.debian.org/20140307094212.GA1695@inutil.org

1 0

[Secure Coding] master: Revert "Yeah, these files are located in their own fhosted repo" (87df308)
by Eric Christensen 24 Mar '14

24 Mar '14

Repository : http://git.fedorahosted.org/git/?p=secure-coding.git On branch : master >--------------------------------------------------------------- commit 87df3083edfb2ff7b22647de13cb5cde9517a193 Author: Eric Christensen <echriste(a)redhat.com> Date: Mon Mar 24 15:59:40 2014 -0400 Revert "Yeah, these files are located in their own fhosted repo" This reverts commit c3c9bf03366425589183febfa961789738a1efb1. >--------------------------------------------------------------- Diff suppressed because of size. To see it, use: git diff --patch-with-stat --no-color --find-copies-harder --ignore-space-at-eol ^87df3083edfb2ff7b22647de13cb5cde9517a193~1 87df3083edfb2ff7b22647de13cb5cde9517a193

1 0

[Secure Coding] master: Yeah, these files are located in their own fhosted repo (c3c9bf0)
by Eric Christensen 24 Mar '14

24 Mar '14

Repository : http://git.fedorahosted.org/git/?p=secure-coding.git On branch : master >--------------------------------------------------------------- commit c3c9bf03366425589183febfa961789738a1efb1 Author: Eric Christensen <echriste(a)redhat.com> Date: Mon Mar 24 14:50:14 2014 -0400 Yeah, these files are located in their own fhosted repo >--------------------------------------------------------------- Diff suppressed because of size. To see it, use: git diff --patch-with-stat --no-color --find-copies-harder --ignore-space-at-eol ^c3c9bf03366425589183febfa961789738a1efb1~1 c3c9bf03366425589183febfa961789738a1efb1

1 0

[Secure Coding] master: Adding Secure Ruby Development Guide (70b828b)
by Eric Christensen 22 Mar '14

22 Mar '14

Repository : http://git.fedorahosted.org/git/?p=secure-coding.git On branch : master >--------------------------------------------------------------- commit 70b828bd71c5dc395209bd330ccdb21ed141e6d9 Author: Eric Christensen <echriste(a)redhat.com> Date: Sat Mar 22 16:30:24 2014 -0400 Adding Secure Ruby Development Guide >--------------------------------------------------------------- Diff suppressed because of size. To see it, use: git diff --patch-with-stat --no-color --find-copies-harder --ignore-space-at-eol ^70b828bd71c5dc395209bd330ccdb21ed141e6d9~1 70b828bd71c5dc395209bd330ccdb21ed141e6d9

1 0

opinions on tcp wrappers?
by Matthew Miller 21 Mar '14

21 Mar '14

I'd love to hear some "official" opinions from the fedora security team on the tcpwrappers thread on the devel list. Thanks! -- Matthew Miller -- Fedora Project -- <mattdm(a)fedoraproject.org>

1 0

F20 efi shim vendor certificate
by Leibowitz, Michael 17 Mar '14

17 Mar '14

Hi, I'm experimenting with UEFI secure boot and am using the Fedora shim. I want to extract the vendor certificate from the shim in the F20 release. I found the section and used obj-copy to extract it, but I can't seem to make sense of the format. Any clues? Thanks -- Michael Leibowitz

1 0

[Secure Coding] master: Fix typos in "Robust argument list processing" section (045ff4f)
by fweimer＠fedoraproject.org 03 Mar '14

03 Mar '14

Repository : http://git.fedorahosted.org/git/?p=secure-coding.git On branch : master >--------------------------------------------------------------- commit 045ff4f71adf238f98f986622a5604d3d431d5e1 Author: Jan Pokorný <jpokorny(a)redhat.com> Date: Sun Mar 2 21:28:36 2014 +0100 Fix typos in "Robust argument list processing" section Signed-off-by: Jan Pokorný <jpokorny(a)redhat.com> >--------------------------------------------------------------- defensive-coding/en-US/Tasks-Processes.xml | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/defensive-coding/en-US/Tasks-Processes.xml b/defensive-coding/en-US/Tasks-Processes.xml index 141232a..8175c21 100644 --- a/defensive-coding/en-US/Tasks-Processes.xml +++ b/defensive-coding/en-US/Tasks-Processes.xml @@ -172,9 +172,9 @@ <title>Robust argument list processing</title> <para> When invoking a program, it is sometimes necessary to include - data from untrusted sources. Such data should be check + data from untrusted sources. Such data should be checked against embedded <literal>NUL</literal> characters because the - system APIs will sliently truncate argument strings at the first + system APIs will silently truncate argument strings at the first <literal>NUL</literal> character. </para> <para>

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

security March 2014