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

[Secure Coding] master: Added RSA key generation procedures (56f3511)

by Eric Christensen

Repository : http://git.fedorahosted.org/git/?p=secure-coding.git On branch : master >--------------------------------------------------------------- commit 56f351145bcdd5edd7d2a00c25e0df4fd665ae7d Author: Eric Christensen <echriste(a)redhat.com> Date: Fri May 30 09:07:40 2014 -0400 Added RSA key generation procedures >--------------------------------------------------------------- Securing_TLS/en-US/OpenSSL.xml | 31 +++++++++++++++++++++++++++++++ 1 files changed, 31 insertions(+), 0 deletions(-) diff --git a/Securing_TLS/en-US/OpenSSL.xml b/Securing_TLS/en-US/OpenSSL.xml index 191564f..df458d9 100644 --- a/Securing_TLS/en-US/OpenSSL.xml +++ b/Securing_TLS/en-US/OpenSSL.xml @@ -160,5 +160,36 @@ EXP-KRB5-RC4-MD5 SSLv3 </para> </section> </section> + <section id="sect-Fedora_Security_Team-Securing_TLS-OpenSSL-Generating_Crypto"> + <title>Generating Crypto</title> + <para>Properly generating keys and certificates is as important as the ciphers suite being used to secure the circuit. The best cipher can be broken with improperly generated keys.</para> + + <section id="sect-Fedora_Security_Team-Securing_TLS-OpenSSL-Generating_Crypto-RSA"> + <title>Generating RSA keys</title> + <para>RSA keys are the most common key type used to secure SSL and TLS circuits. It's relatively simple to generate keys and we'll describe how and why now.</para> + <para> +<screen> +openssl genrsa -aes128 -out key_name.key 3072 +</screen> +This will generate a 3072-bit RSA key that is sufficently large for true 128 bits of security. To obtain 256 bits of security the RSA key will need to be 15360 bits. If you require that type of security, however, a ECDSA key should be utilized. +<important><para>The industry standard 2048-bit RSA key only provides 112 bits of security.<footnote><para>NIST SP 800-57 Part 1, Rev 3 <ulink url="http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_gen..." /></para></footnote></para></important> + +<screen> +openssl rsa -in key_name.key -out key_name.key +</screen> +This simply removes the password that was placed on the key at generation. You can do this once you are sure you no longer need to protect the key (like when it's going to be used on the server). + +<screen> +openssl req -new -key key_name.key -out key_name.csr +</screen> +This will generate a certificate signing request (<abbrev>CSR</abbrev>) to provide to your certificate authority (<abbrev>CA</abbrev>) for signing. + +<screen> +openssl x509 -req -days 365 -sha384 -in key_name.csr -signkey key_name.key -out key_name.crt +</screen> +<emphasis>Optional</emphasis> - This last step isn't generally necessary. This is what the CA does on their side except they use their key in place of key_name.key to sign your key. By doing this you are creating a self-signed certificate which is not very useful and should only be used for testing purposes. + </para> + </section> + </section> </chapter>

9 years, 10 months

3
3
0 / 0

Review of obs-sign

by Miroslav Suchý

Hi guys, I would like to use obs-sign for signing packages in Copr. Since this will be important part of Fedora, I would be glad if more people can see it and point out some problem if there are any. I already discussed it with Mitr, but more eyes is always better. This is little bit premature, since I do not have rpm package ready yet (will be in 2 weeks aprox.). The code is here: https://github.com/openSUSE/obs-sign Docs here: http://en.opensuse.org/openSUSE:Build_Service_Signer -- Miroslav Suchy, RHCE, RHCDS Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys

9 years, 10 months

6
8
0 / 0

[Secure Coding] master: C: Add example for unsigned overflow check (e97e4dc)

by fweimer＠fedoraproject.org

Repository : http://git.fedorahosted.org/git/?p=secure-coding.git On branch : master >--------------------------------------------------------------- commit e97e4dc0e06ef037b2042a251c17e1f4a66ccc66 Author: Florian Weimer <fweimer(a)redhat.com> Date: Fri Jun 6 16:49:27 2014 +0200 C: Add example for unsigned overflow check >--------------------------------------------------------------- defensive-coding/en-US/C-Language.xml | 11 +++++++++++ ...etic-mult.xml => C-Arithmetic-add_unsigned.xml} | 9 ++++++--- defensive-coding/src/C-Arithmetic-add.c | 14 ++++++++++++++ 3 files changed, 31 insertions(+), 3 deletions(-) diff --git a/defensive-coding/en-US/C-Language.xml b/defensive-coding/en-US/C-Language.xml index b1eeec0..8f6f74d 100644 --- a/defensive-coding/en-US/C-Language.xml +++ b/defensive-coding/en-US/C-Language.xml @@ -103,8 +103,19 @@ <para> Perform the calculation in the corresponding unsigned type and use bit fiddling to detect the overflow. + <xref linkend="ex-Defensive_Coding-C-Arithmetic-add_unsigned"/> + shows how to perform an overflow check for unsigned integer + addition. For three or more terms, all the intermediate + additions have to be checked in this way. </para> </listitem> + </itemizedlist> + <example id="ex-Defensive_Coding-C-Arithmetic-add_unsigned"> + <title>Overflow checking for unsigned addition</title> + <xi:include href="snippets/C-Arithmetic-add_unsigned.xml" + xmlns:xi="http://www.w3.org/2001/XInclude" /> + </example> + <itemizedlist> <listitem> <para> Compute bounds for acceptable input values which are known diff --git a/defensive-coding/en-US/snippets/C-Arithmetic-mult.xml b/defensive-coding/en-US/snippets/C-Arithmetic-add_unsigned.xml similarity index 68% copy from defensive-coding/en-US/snippets/C-Arithmetic-mult.xml copy to defensive-coding/en-US/snippets/C-Arithmetic-add_unsigned.xml index ecb27a0..4ea1747 100644 --- a/defensive-coding/en-US/snippets/C-Arithmetic-mult.xml +++ b/defensive-coding/en-US/snippets/C-Arithmetic-add_unsigned.xml @@ -3,12 +3,15 @@ ]>  <programlisting language="C"> +void report_overflow(void); + unsigned -mul(unsigned a, unsigned b) +add_unsigned(unsigned a, unsigned b) { - if (b && a > ((unsigned)-1) / b) { + unsigned sum = a + b; + if (sum < a) { // or sum < b report_overflow(); } - return a * b; + return sum; } </programlisting> diff --git a/defensive-coding/src/C-Arithmetic-add.c b/defensive-coding/src/C-Arithmetic-add.c index 3e70286..95b403e 100644 --- a/defensive-coding/src/C-Arithmetic-add.c +++ b/defensive-coding/src/C-Arithmetic-add.c @@ -15,3 +15,17 @@ add(int a, int b) return result; } //- + +//+ C Arithmetic-add_unsigned +void report_overflow(void); + +unsigned +add_unsigned(unsigned a, unsigned b) +{ + unsigned sum = a + b; + if (sum < a) { // or sum < b + report_overflow(); + } + return sum; +} +//-

9 years, 10 months

1
0
0 / 0

[Secure Coding] master: Serialization: Add section on fragmentation and reassembly (01bd390)

by fweimer＠fedoraproject.org

Repository : http://git.fedorahosted.org/git/?p=secure-coding.git On branch : master >--------------------------------------------------------------- commit 01bd3904dc2a71c18727a4ddd7bd53f1bc56a929 Author: Florian Weimer <fweimer(a)redhat.com> Date: Fri Jun 6 15:03:32 2014 +0200 Serialization: Add section on fragmentation and reassembly >--------------------------------------------------------------- defensive-coding/en-US/Tasks-Serialization.xml | 130 ++++++++++++++++++++++++ 1 files changed, 130 insertions(+), 0 deletions(-) diff --git a/defensive-coding/en-US/Tasks-Serialization.xml b/defensive-coding/en-US/Tasks-Serialization.xml index 008e75b..81ba061 100644 --- a/defensive-coding/en-US/Tasks-Serialization.xml +++ b/defensive-coding/en-US/Tasks-Serialization.xml @@ -42,6 +42,136 @@ characters simplifies testing and debugging. However, binary protocols with length fields may be more efficient to parse. </para> + <para> + In new datagram-oriented protocols, unique numbers such as + sequence numbers or identifiers for fragment reassembly (see + <xref + linkend="sect-Defensive_Coding-Tasks-Serialization-Fragmentation"/>) + should be at least 64 bits large, and really should not be + smaller than 32 bits in size. Protocols should not permit + fragments with overlapping contents. + </para> + </section> + + <section id="sect-Defensive_Coding-Tasks-Serialization-Fragmentation"> + <title>Fragmentation</title> + <para> + Some serialization formats use frames or protocol data units + (PDUs) on lower levels which are smaller than the PDUs on higher + levels. With such an architecture, higher-level PDUs may have + to be <emphasis>fragmented</emphasis> into smaller frames during + serialization, and frames may need + <emphasis>reassembly</emphasis> into large PDUs during + deserialization. + </para> + <para> + Serialization formats may use conceptually similar structures + for completely different purposes, for example storing multiple + layers and color channels in a single image file. + </para> + <para> + When fragmenting PDUs, establish a reasonable lower bound for + the size of individual fragments (as large as possible—limits as + low as one or even zero can add substantial overhead). Avoid + fragmentation if at all possible, and try to obtain the maximum + acceptable fragment length from a trusted data source. + </para> + <para> + When implementing reassembly, consider the following aspects. + </para> + <itemizedlist> + <listitem> + <para> + Avoid allocating significant amount of resources without + proper authentication. Allocate memory for the unfragmented + PDU as more and more and fragments are encountered, and not + based on the initially advertised unfragmented PDU size, + unless there is a sufficiently low limit on the unfragmented + PDU size, so that over-allocation cannot lead to performance + problems. + </para> + </listitem> + <listitem> + <para> + Reassembly queues on top of datagram-oriented transports + should be bounded, both in the combined size of the arrived + partial PDUs waiting for reassembly, and the total number of + partially reassembled fragments. The latter limit helps to + reduce the risk of accidental reassembly of unrelated + fragments, as it can happen with small fragment IDs (see + <xref linkend="sect-Defensive_Coding-Tasks-Serialization-Fragmentation-ID"/>). + It also guards to some extent against deliberate injection of fragments, + by guessing fragment IDs. + </para> + </listitem> + <listitem> + <para> + Carefully keep track of which bytes in the unfragmented PDU + have been covered by fragments so far. If message + reordering is a concern, the most straightforward data + structure for this is an array of bits, with one bit for + every byte (or other atomic unit) in the unfragmented PDU. + Complete reassembly can be determined by increasing a + counter of set bits in the bit array as the bit array is + updated, taking overlapping fragments into consideration. + </para> + </listitem> + <listitem> + <para> + Reject overlapping fragments (that is, multiple fragments + which provide data at the same offset of the PDU being + fragmented), unless the protocol explicitly requires + accepting overlapping fragments. The bit array used for + tracking already arrived bytes can be used for this purpose. + </para> + </listitem> + <listitem> + <para> + Check for conflicting values of unfragmented PDU lengths (if + this length information is part of every fragment) and + reject fragments which are inconsistent. + </para> + </listitem> + <listitem> + <para> + Validate fragment lengths and offsets of individual + fragments against the unfragmented PDU length (if they are + present). Check that the last byte in the fragment does not + lie after the end of the unfragmented PDU. Avoid integer + overflows in these computations (see <xref + linkend="sect-Defensive_Coding-C-Arithmetic"/>). + </para> + </listitem> + </itemizedlist> + <section id="sect-Defensive_Coding-Tasks-Serialization-Fragmentation-ID"> + <title>Fragment IDs</title> + <para> + If the underlying transport is datagram-oriented (so that PDUs + can be reordered, duplicated or be lost, like with UDP), + fragment reassembly needs to take into account endpoint + addresses of the communication channel, and there has to be + some sort of fragment ID which identifies the individual + fragments as part of a larger PDU. In addition, the + fragmentation protocol will typically involve fragment offsets + and fragment lengths, as mentioned above. + </para> + <para> + If the transport may be subject to blind PDU injection (again, + like UDP), the fragment ID must be generated randomly. If the + fragment ID is 64 bit or larger (strongly recommended), it can + be generated in a completely random fashion for most traffic + volumes. If it is less than 64 bits large (so that accidental + collisions can happen if a lot of PDUs are transmitted), the + fragment ID should be incremented sequentially from a starting + value. The starting value should be derived using a HMAC-like + construction from the endpoint addresses, using a long-lived + random key. This construction ensures that despite the + limited range of the ID, accidental collisions are as unlikely + as possible. (This will not work reliable with really short + fragment IDs, such as the 16 bit IDs used by the Internet + Protocol.) + </para> + </section> </section> <section>

9 years, 10 months

1
0
0 / 0

[Secure Coding] master: Packaging: Adjust RPM flags of key-related files (f5803d1)

by fweimer＠fedoraproject.org

Repository : http://git.fedorahosted.org/git/?p=secure-coding.git On branch : master >--------------------------------------------------------------- commit f5803d1403f9adf1cb54dd5ab93bb649d5e07c88 Author: Florian Weimer <fweimer(a)redhat.com> Date: Fri Jun 6 13:32:50 2014 +0200 Packaging: Adjust RPM flags of key-related files >--------------------------------------------------------------- defensive-coding/en-US/Tasks-Packaging.xml | 17 +++++++++++++---- 1 files changed, 13 insertions(+), 4 deletions(-) diff --git a/defensive-coding/en-US/Tasks-Packaging.xml b/defensive-coding/en-US/Tasks-Packaging.xml index 5562f45..3e3feab 100644 --- a/defensive-coding/en-US/Tasks-Packaging.xml +++ b/defensive-coding/en-US/Tasks-Packaging.xml @@ -86,11 +86,20 @@ fi %files %dir %attr(0755,%{tlsuser},%{tlsuser]) %{tlsdir} -%ghost %attr(0600,%{tlsuser},%{tlsuser}) %{tlskey} -%ghost %attr(0644,%{tlsuser},%{tlsuser}) %{tlscert} +%ghost %attr(0600,%{tlsuser},%{tlsuser}) %config(noreplace) %{tlskey} +%ghost %attr(0644,%{tlsuser},%{tlsuser}) %config(noreplace) %{tlscert} </programlisting> </example> <para> + The files containing the key material are marked as ghost + configuration files. This ensures that they are tracked in the + RPM database as associated with the package, but RPM will not + create them when the package is installed and not verify their + contents (the <literal>%ghost</literal>), or delete the files + when the package is uninstalled (the + <literal>%config(noreplace)</literal> part). + </para> + <para> If the <emphasis>directory</emphasis> <literal>%{tlsdir}</literal> <emphasis>is owned by</emphasis> <literal>root</literal>, use the code in <xref @@ -114,8 +123,8 @@ fi %files %dir %attr(0755,root,root]) %{tlsdir} -%ghost %attr(0600,%{tlsuser},%{tlsuser}) %{tlskey} -%ghost %attr(0644,root,root) %{tlscert} +%ghost %attr(0600,%{tlsuser},%{tlsuser}) %config(noreplace) %{tlskey} +%ghost %attr(0644,root,root) %config(noreplace) %{tlscert} </programlisting> </example> <para>

9 years, 10 months

1
0
0 / 0

[Secure Coding] master: Packaging: Fix RPM macro issue (11ef1e6)

by fweimer＠fedoraproject.org

Repository : http://git.fedorahosted.org/git/?p=secure-coding.git On branch : master >--------------------------------------------------------------- commit 11ef1e626053e2562a03c90eee67acb8c93f26af Author: Florian Weimer <fweimer(a)redhat.com> Date: Fri Jun 6 13:27:43 2014 +0200 Packaging: Fix RPM macro issue >--------------------------------------------------------------- defensive-coding/en-US/Tasks-Packaging.xml | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/defensive-coding/en-US/Tasks-Packaging.xml b/defensive-coding/en-US/Tasks-Packaging.xml index 07ee072..5562f45 100644 --- a/defensive-coding/en-US/Tasks-Packaging.xml +++ b/defensive-coding/en-US/Tasks-Packaging.xml @@ -113,9 +113,9 @@ if [ $1 -eq 1 ] ; then fi %files -%dir %attr(0755,%{root},%{root}]) %{tlsdir} +%dir %attr(0755,root,root]) %{tlsdir} %ghost %attr(0600,%{tlsuser},%{tlsuser}) %{tlskey} -%ghost %attr(0644,%{root},%{root}) %{tlscert} +%ghost %attr(0644,root,root) %{tlscert} </programlisting> </example> <para>

9 years, 10 months

1
0
0 / 0

[Secure Coding] master: Packaging: Add section on delayed certificate generation (dc0ff1a)

by fweimer＠fedoraproject.org

Repository : http://git.fedorahosted.org/git/?p=secure-coding.git On branch : master >--------------------------------------------------------------- commit dc0ff1a16e89bdd14cf0f157bacc40a15367702f Author: Florian Weimer <fweimer(a)redhat.com> Date: Fri Jun 6 13:26:37 2014 +0200 Packaging: Add section on delayed certificate generation >--------------------------------------------------------------- defensive-coding/en-US/Tasks-Packaging.xml | 37 +++++++++++++++++++++++++++- 1 files changed, 36 insertions(+), 1 deletions(-) diff --git a/defensive-coding/en-US/Tasks-Packaging.xml b/defensive-coding/en-US/Tasks-Packaging.xml index 95bfbc6..07ee072 100644 --- a/defensive-coding/en-US/Tasks-Packaging.xml +++ b/defensive-coding/en-US/Tasks-Packaging.xml @@ -20,7 +20,8 @@ such use, generating the key pair at package installation time when preparing system images for use in the cluster is reasonable. For other use cases, it is necessary to generate - the key pair before the service is started for the first time. + the key pair before the service is started for the first time, + see <xref linkend="sect-Defensive_Coding-Tasks-Packaging-Certificates-Service"/>. </para> <important> <para> @@ -128,4 +129,38 @@ fi <application>chmod</application> invocation. </para> </section> + <section id="sect-Defensive_Coding-Tasks-Packaging-Certificates-Service"> + <title>Generating X.509 self-signed certificates before service + start</title> + <para> + An alternative way to automatically provide an X.509 key pair is + to create it just before the service is started for the first + time. This ensures that installation images which are created + from installed RPM packages receive different key material. + Creating the key pair at package installation time (see <xref + linkend="sect-Defensive_Coding-Tasks-Packaging-Certificates"/>) + would put the key into the image, which may or may not make + sense. + </para> + <important> + <para> + The caveats about the way the key is generated in <xref + linkend="sect-Defensive_Coding-Tasks-Packaging-Certificates"/> + apply to this procedure as well. + </para> + </important> + <para> + Generating key material before service start may happen very + early during boot, when the kernel randomness pool has not yet + been initialized. Currently, the only way to check for the + initialization is to look for the kernel message + <literal>random: nonblocking pool is initialized</literal>. In + theory, it is also possible to read from + <filename>/dev/random</filename> while generating the key + material (instead of <filename>/dev/urandom</filename>), but + this can block not just during the boot process, but also much + later at run time, and generally results in a poor user + experience. + </para> + </section> </chapter>

9 years, 10 months

1
0
0 / 0

available crypto policies

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

OpenSSL MITM CCS injection attack (CVE-2014-0224)

by Eric Christensen

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Fedora, this morning, released the latest version of OpenSSL which fixes a MITM CCS injection attack (CVE-2014-0224). This vulnerability made a man-in-the-middle attack possible when both sides were using a vulnerable OpenSSL implementation. It is highly recommended that all users update their openssl packages (sudo yum update openssl) and verify that they have the openssl-1.0.1e-38 RPM installed. A restart of any service that is using OpenSSL is required for this fix to become active. Additional information can be found on the Red Hat Security Blog[0] or the errata[1][2]. [0] https://securityblog.redhat.com/2014/06/05/openssl-mitm-ccs-injection-att... [1] https://admin.fedoraproject.org/updates/openssl-1.0.1e-38.fc20 [2] https://admin.fedoraproject.org/updates/openssl-1.0.1e-38.fc19 - -- Eric - -------------------------------------------------- Eric "Sparks" Christensen Fedora Project Security Team Red Hat Product Security sparks(a)fedoraproject.org - sparks(a)redhat.com 097C 82C3 52DF C64A 50C2 E3A3 8076 ABDE 024B B3D1 - -------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQGcBAEBCgAGBQJTkHx1AAoJEB/kgVGp2CYv8NEL/jj6Z4gmgKUM6f/Gva7HO/jX S/rGKWwAoErsjj+Te5pw0Y5uajHnVnsL5BschH9oRSWrJdrc2IInZJpdec2/rGwr 37OmIl64aRYZhamTJE+JE+bAt74TxLlBmk7BHxEyAEp8+aMaXbgML2wrB5/BBJ+d AuS7F/IlG0BDHyQ4i9FQfEEmt98KP9TGGphHx6pNKyQ7uxf/BVjk8su2YwQ7cvKq eJBARdcK5YX+qu6cf1PFasEWie4DWZSvHo0YznG1zlYQkOnn4gPyLnRqLV32CFC2 WbXljyieyWD2AaU/5BYaHQ/HXCU08tU93RQyUTGyLTqIvV0Ikcwjxy0KKB/4MUuH TP2iuh5p5ZinAi1zEcUNV8R35KVukTNGUZz+h4pCXL2ylJt6bJZIPyq+lZ+keORZ I/ea+IsoFlzzzPVvD8nuSwsSCtM04R4I0nFNuwFLFqVT5vJYfiMgmDqJbJM1wM4G VefBRhbqy8yJnc+XF+zmKY5S626HFEjyAtRW4OfnMw== =5st6 -----END PGP SIGNATURE-----

9 years, 10 months

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] June 2014