March 2014 - security [ARCHIVED] - Fedora Mailing-Lists

by Nikos Mavrogiannopoulos

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+

9 years, 10 months

12
52
0 / 0

Crypto guidelines for Fedora

by Till Maas

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/delivera... 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

10 years

6
12
0 / 0

Enable GCC hardening by default

by Florian Weimer

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

10 years

1
0
0 / 0

[Secure Coding] master: Revert "Yeah, these files are located in their own fhosted repo" (87df308)

by Eric Christensen

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

10 years, 1 month

1
0
0 / 0

[Secure Coding] master: Yeah, these files are located in their own fhosted repo (c3c9bf0)

by Eric Christensen

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

10 years, 1 month

1
0
0 / 0

[Secure Coding] master: Adding Secure Ruby Development Guide (70b828b)

by Eric Christensen

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

10 years, 1 month

1
0
0 / 0

opinions on tcp wrappers?

by Matthew Miller

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>

10 years, 1 month

1
0
0 / 0

F20 efi shim vendor certificate

by Leibowitz, Michael

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

10 years, 1 month

1
0
0 / 0

[Secure Coding] master: Fix typos in "Robust argument list processing" section (045ff4f)

by fweimer＠fedoraproject.org

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>

10 years, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

security [ARCHIVED] March 2014