Bug 1324493

Summary: Update the list of FIPS approved algorithms
Product: [Fedora] Fedora Reporter: Tomas Mraz <tmraz>
Component: opensshAssignee: Jakub Jelen <jjelen>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: jjelen, mattias.ellert, mgrepl, plautrba, tmraz
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: openssh-7.2p2-4.fc24 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-04-18 17:24:32 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
backtrace from SIGSYS in FIPS mode none

Description Tomas Mraz 2016-04-06 13:18:48 UTC 
The current list of FIPS algorithms in openssh is wrong and contains some non-approved ciphers but it is missing some approved ones.

The list should be for ciphers:
3des-cbc
aes128-cbc
aes192-cbc
aes256-cbc
rijndael-cbc.se
aes128-ctr
aes192-ctr
aes256-ctr
Note that means removing aes-gcm as that is not approved for use with anything else than IPSec and TLS in FIPS.

for macs:
I'd remove the sha1-96 macs at least. I'd keep the sha1 macs as that might be needed for interoperability however it's status is questionable.

for kex:
I'd remove key exchanges that use sha1. We'll see if the interoperability with so limited key exchange methods will be reasonable.
Comment 1 Jakub Jelen 2016-04-11 11:13:57 UTC 
Thanks for the report. I will update the list with next update.

* I will remove the *gcm ciphers from FIPS mode available ciphers. It is not in default proposal, but it still can be selected:

    # ssh -oCiphers=aes256-gcm -G test | grep gcm
    FIPS mode initialized
    ciphers aes256-gcm

* The  mac sha1-96  is not in default proposal (even for non-FIPS) and it does not work in FIPS:

    $ ssh -oMACs=hmac-sha1-96 -G test | grep hmac-sha1-96
    command-line line 0: Bad SSH2 Mac spec 'hmac-sha1-96'.

* About Kex, I see in default proposal

    diffie-hellman-group-exchange-sha1,
    diffie-hellman-group14-sha1

where, both of them are still in FIPS default proposal. We can remove them from FIPS list. The  diffie-hellman-group1-sha1  is already disabled.
Comment 2 Tomas Mraz 2016-04-11 11:31:00 UTC 
(In reply to Jakub Jelen from comment #1)

> * About Kex, I see in default proposal
> 
>     diffie-hellman-group-exchange-sha1,
>     diffie-hellman-group14-sha1
> 
> where, both of them are still in FIPS default proposal. We can remove them
> from FIPS list. The  diffie-hellman-group1-sha1  is already disabled.

OK, please remove them from the FIPS list.
Comment 3 Jakub Jelen 2016-04-11 13:19:03 UTC 
Interesting enough, ecdh-sha2-nistp*, key exchanges are failing in FIPS mode (server side), because of SECCOMP (with PrivilegeSeparation sandbox). Investigating the reasons ...

I see  SIGSYS  under  fips_check_ec(). Any idea what is there different in FIPS related to syscalls?

ssh_sandbox_violation: unexpected system call (arch:0xc000003e,syscall:41 @ 0x7f2dbf827c07) [preauth]

[root@f23 ~]# ausyscall 41
socket

Tomas, do you have some idea why does openssl need  socket  syscall in FIPS mode (in preauth)? It does not happen without FIPS.
Comment 4 Tomas Mraz 2016-04-11 13:37:31 UTC 
You mean it does socket() syscall? That's weird. I do not see anything like that in the code. Can you strace it or find the backtrace via gdb?
Comment 5 Jakub Jelen 2016-04-11 13:44:47 UTC 
Created attachment 1146003 [details]
backtrace from SIGSYS in FIPS mode

Added as an attachment. It is quite long. Let me know if I should get something more. And I hope it is not my machine broken.
Comment 6 Tomas Mraz 2016-04-11 13:58:33 UTC 
OK, that is legitimate call although it is not needed and it can fail. I do not know whether it is possible to make some syscalls fail without the SIGSYS with the seccomp.
Comment 7 Jakub Jelen 2016-04-11 14:03:58 UTC 
Yes, we can tell  seccomp  to fail with various return codes if the syscall is not allowed. EACCESS is probably most appropriate.

Thank you for the comments. I will test if there will not show up something else and cover it with the next update.
Comment 8 Jakub Jelen 2016-04-11 14:18:30 UTC 
Tested and works fine. I pushed the changes to dist-git. Builds will come later. It does not look critical since nobody noticed for a year since we enabled seccomp.
Comment 10 Fedora Update System 2016-04-15 16:47:46 UTC 
openssh-7.2p2-4.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-965bd6926e
Comment 11 Fedora Update System 2016-04-15 23:21:12 UTC 
openssh-7.2p2-4.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-965bd6926e
Comment 12 Fedora Update System 2016-04-18 17:24:25 UTC 
openssh-7.2p2-4.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.