RHEL6 SSG Bug (SSH,Ciphers)

Jan Lieskovsky jlieskov at redhat.com
Thu Jun 11 15:49:12 UTC 2015


----- Original Message -----
> From: "Lesley Kimmel" <ljkimmel99 at hotmail.com>
> To: "Jan Lieskovsky" <jlieskov at redhat.com>
> Cc: "SCAP Security Guide" <scap-security-guide at lists.fedorahosted.org>
> Sent: Thursday, June 11, 2015 4:47:28 PM
> Subject: RE: RHEL6 SSG Bug (SSH,Ciphers)
> 
> I am actually running this against a RHEL7 system at the moment. I have added
> '<platform idref="cpe:/o:redhat:enterprise_linux:7"/>' to allow it to run. I
> figure this shouldn't matter since it's just doing a pattern match against a
> properties file that's essentially the same on RHEL6 and RHEL7.  I am using
> the default profile 'C2S for Red Hat Enterprise Linux 6'. I am then
> tailoring, deselecting all and then only selecting the following:
> 
> -Group 'Configure OpenSSH Server if Necessary'
> --Allow only ssh protocol 2
> --Set SSH idle timeout interval
> --Set ssh client alive count
> --Disable host-based authentication
> --Disable SSH Root Login
> --Disable SSH Access via Empty passwords
> --Enable ssh warning banner
> --Do not allow ssh environment options
> --Use only approved ciphers
> 
> I built the system manually without any kickstart. I have not yet edited the
> sshd_config file and I see that some of the items being checked are in the
> sshd_config file but are commented out. When I run the scan all of these
> items pass. As an example, tst:470 checks for 'ClientAliveCountMax'. It uses
> 'check-existence='all_exist' which I assume means that it requires this
> value to be found in the config file. This refers to obj:1523 which looks
> for the following pattern:
> 
> ^[\s]*(?i)ClientAliveCountMax[\s]+([\d]+)[\s]*(?:|(?:#.*))?$
> 
> I interpret this as checking for a line that starts with (case insensitive)
> ClientAliveCountMax followed by one or more spaces and one or more digits.
> I'm not sure the point of (?:|(?:#.*))?.

The "(?:|" part of the pattern above was added to allow the check to succeed if the
ClientAliveCountMax directive would be present as the last one in the
/etc/ssh/sshd_config file (IOW 'ClientAliveCountMax digit' would be last
item before EOF without the newline).

And "(?:#.*)" handles case when 'ClientAliveCountMax digit' would be followed by
comment in sshd_config, IOW it would have the form of:

  ClientAliveCountMax digit # Set ClientAliveCountMax to digit per security requirements

where 'digit' would be the actual number.

Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Technologies Team

> I assume that it was intended to
> possibly allow for the possibility of the keyword not existing or being
> commented out. However, because all of the stuff at the beginning of the
> line is not grouped I think it is mandatory and this should be checking
> firmly for the existence of an uncommented line beginning with
> 'ClientAliveCountMax'. While it does not exist in the config file it still
> passes. There must be something else going on here.
> 
> > Date: Thu, 11 Jun 2015 10:18:54 -0400
> > From: jlieskov at redhat.com
> > To: ljkimmel99 at hotmail.com
> > CC: scap-security-guide at lists.fedorahosted.org
> > Subject: Re: RHEL6 SSG Bug (SSH,Ciphers)
> > 
> > Hello Lesley,
> > 
> >   thank you for your reply.
> > 
> > ----- Original Message -----
> > > From: "Lesley Kimmel" <ljkimmel99 at hotmail.com>
> > > To: "Jan Lieskovsky" <jlieskov at redhat.com>
> > > Cc: "SCAP Security Guide" <scap-security-guide at lists.fedorahosted.org>
> > > Sent: Thursday, June 11, 2015 3:31:14 PM
> > > Subject: RE: RHEL6 SSG Bug (SSH,Ciphers)
> > > 
> > > Jan;
> > > 
> > > Thanks for the detailed feedback. I understand the reasoning now. I also
> > > think that it is always safest to go ahead and explicitly place those
> > > options in the configuration files (in this case sshd_config). My
> > > concern,
> > > though, is that without having modified sshd_config AT ALL every OVAL
> > > check
> > > passed.
> > 
> > Assuming here you mean all sshd checks passed without any change being
> > performed
> > to sshd_config. Can you be more specific which profile you used for scan
> > and also
> > which Red Hat Enterprise Linux 6 version was this scan performed at? Was it
> > RHEL-6.7
> > Beta already?
> > 
> > I will try to reproduce the behaviour in between but as much as possible
> > concrete
> > details would be helpful to identify the reason quicker.
> > 
> > Just to confirm, the system in question having the above behaviour wasn't
> > installed
> > using on of the kickstarts from the RHEL/6/kickstart directory, right?
> > (because
> > in that case it would be expected all the rules would pass when performing
> > a scan).
> > 
> > > Typically, I run the SCAP tools once to give me a starting point and
> > > begin fixing the Failed and Unchecked items from there. Had I not had so
> > > much experience hardening RHEL systems I would have overlooked these sshd
> > > configurations because they all reported as passed. I would submit that
> > > these tests should all fail if the setting is not present and
> > > uncommented.
> > > 
> > > Also, on a more general note/question would it be possible to do a "match
> > > all" type of scenario for configuration directives with many required
> > > options/arguments so that it wasn't necessary to ensure that they match
> > > the
> > > exact order specified in the OVAL check. For example, I was configuring
> > > auditd yesterday. I copied stig.rules from /usr/share/doc/audit-<version>
> > > to
> > > /etc/audit/rules.d. Even though the items in stig.rules meet all of the
> > > requirements outlined in the SSG many of the checks fail because the
> > > options
> > > aren't listed in the same order as they are in the OVAL. Here's a
> > > concrete
> > > example:
> > > 
> > > stig.rules contains:
> > > -a always,exit -F arch=b32 -S creat -S open -S openat -S
> > > open_by_handle_at -S
> > > truncate -F exit=-EACCES -f auid>=500 -F auid!=4294967295 -k acess
> > > 
> > > The OVAL, in this case, checks for:
> > > ^\-a\s+always,exit\s+(\-F\s+arch=(b64|b32)\s+)?\-S\s+creat\s+\-S\s+open\s+\-S\s+openat\s+\-S\s+truncate\s+\-S\s+ftruncate\s+\-F\s+exit=\-EPERM\s+\-F\s+auid&gt;=500\s+\-F\s+auid!=4294967295\s+\-k\s+[-\w]+\s*$
> > > 
> > > As you can tell the 'stig.rules' contains an extra syscall
> > > (open_by_handle_at) which will cause this check to always fail unless
> > > either
> > > the OVAL is updated or the audit rule is modified to match the check
> > > exactly. It might make more sense to check multiple patterns and require
> > > that they all pass:
> > > 
> > > ^\-a\s+always,exit\s+(\-F\s+arch=(b64|b32)\s+)?.*\-S\s+creat.*\-F\s+exit=\-EPERM\s+\-F\s+auid&gt;=500\s+\-F\s+auid!=4294967295\s+\-k\s+[-\w]+\s*$
> > > AND
> > > ^\-a\s+always,exit\s+(\-F\s+arch=(b64|b32)\s+)?.*\-S\s+open.*\-F\s+exit=\-EPERM\s+\-F\s+auid&gt;=500\s+\-F\s+auid!=4294967295\s+\-k\s+[-\w]+\s*$
> > > AND
> > > ^\-a\s+always,exit\s+(\-F\s+arch=(b64|b32)\s+)?.*\-S\s+openat.*\-F\s+exit=\-EPERM\s+\-F\s+auid&gt;=500\s+\-F\s+auid!=4294967295\s+\-k\s+[-\w]+\s*$
> > > AND
> > > ^\-a\s+always,exit\s+(\-F\s+arch=(b64|b32)\s+)?.*\-S\s+truncate.*\-F\s+exit=\-EPERM\s+\-F\s+auid&gt;=500\s+\-F\s+auid!=4294967295\s+\-k\s+[-\w]+\s*$
> > > 
> > > Note the '.*' bookending the actual syscall being matched in each test.
> > 
> > This looks like reasonable request / enhancement. We are trying to write
> > audit / OVAL rules in general as tight as possible, so they wouldn't allow
> > invalid configurations. But on the other hand they should be flexible
> > enough
> > to allow / PASS on different forms of valid configuration(s).
> > 
> > > 
> > > Although I am aware that this begins to make the OVAL content much more
> > > bulky
> > > and we are probably trying to make it as terse as possible.
> > 
> > The OVAL content doesn't need to be terse. It should be readable (read as
> > after
> > looking at it it should be visible what's it is doing), but doesn't
> > necessarily
> > need to be short, when / where more complexity is necessary it to be
> > appropriate.
> > 
> > > This is probably
> > > also a special case because most services don't include templates like
> > > auditd. Anyway, I'm just trying to open up a discussion and possibly help
> > > out.
> > 
> > There's always space for enhancements. Couple of months ago we didn't even
> > have
> > audit OVAL checks for all audit rules. Now we have them (or at least for
> > majority
> > of them AFAICT), and we definitely can / should enhance them to properly
> > handle
> > all the nuances of the correct configuration(s).
> > 
> > > 
> > > Let me know if I can help.
> > 
> > Depends on the way you are willing to help. You are helping already showing
> > us to see the issues not seen till now :) (or seen already, but not finding
> > time to address them till now).
> > 
> > But if you want to help even more (like want to create concrete patches and
> > GitHub pull requests for review), you are definitely welcome to do so
> > (more eyes can recognize more issues and even fix them quicker).
> > 
> > Thank you && Regards, Jan.
> > --
> > Jan iankko Lieskovsky / Red Hat Security Technologies Team
> > 
> > > 
> > > Thanks again!
> > > -Lesley Kimmel
> > > 
> > > > Date: Thu, 11 Jun 2015 05:27:15 -0400
> > > > From: jlieskov at redhat.com
> > > > To: ljkimmel99 at hotmail.com
> > > > CC: scap-security-guide at lists.fedorahosted.org
> > > > Subject: Re: RHEL6 SSG Bug (SSH,Ciphers)
> > > > 
> > > > Hello Lesley,
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Lesley Kimmel" <ljkimmel99 at hotmail.com>
> > > > > To: "SSG" <scap-security-guide at lists.fedorahosted.org>
> > > > > Sent: Thursday, June 11, 2015 12:14:56 AM
> > > > > Subject: RHEL6 SSG Bug (SSH,Ciphers)
> > > > > 
> > > > > All;
> > > > > 
> > > > > I ran into a bug in the latest SSG for RHEL6 (0.1.21-2). There is
> > > > > definitely
> > > > > an issue with the check for approved Ciphers. Initially the check
> > > > > passed
> > > > > with no entry at all for Ciphers. I then placed a Cipher line with
> > > > > (1)
> > > > > valid
> > > > > cipher: pass. Finally I put an entry in sshd_config with a bogus
> > > > > cipher:
> > > > > passed. I just ran into this at the end of my workday today so I
> > > > > didn't
> > > > > get
> > > > > much of a chance to analyze it. Plus I'm really just starting to dig
> > > > > into
> > > > > the 'innards' of the content so I don't fully realize the connections
> > > > > of
> > > > > all
> > > > > the various sections (rule/def/tst/obj/ste).
> > > > 
> > > > Thank you for the report. I will have a look into this issue && report
> > > > the
> > > > findings back once obtained.
> > > > 
> > > > > I'm also pretty sure that some
> > > > > of the other checks against sshd_config are off. The check for
> > > > > 'PermitRootLogin no' passed even though the file contains
> > > > > '#PermitRootLogin
> > > > > yes
> > > > 
> > > > For this part it is possible the corresponding regular expression
> > > > doesn't
> > > > honours comments properly. I will double check that (btw would be good
> > > > if you could try the very same with the most recent scap-security-guide
> > > > 0.1.22 version from upstream's Git, since it's possible it got
> > > > corrected
> > > > upstream
> > > > in between already). But I will double check that, and report back.
> > > > 
> > > > >' and typically the checks are looking for the presence of the target
> > > > > string, not the absence of it.
> > > > 
> > > > For the last part ("the checks are looking for the presence of the
> > > > target
> > > > string, not the absence of it" - this is motivated by the "nature" of
> > > > the
> > > > sshd service and it's config file /etc/ssh/sshd_config.
> > > > 
> > > > A bit longer story about sshd hopefully without too much gory details
> > > > being
> > > > as follows - sshd besides loading settings from /etc/sshd/sshd_config
> > > > file
> > > > honours also internal "default" options / settings. To mention an
> > > > example
> > > > --
> > > > "Protocol 2" directive has become a default setting starting from
> > > > certain
> > > > sshd version. The implication of these internal "default" settings
> > > > being
> > > > that in order to obtain the exact sshd configuration, that will be
> > > > actually
> > > > used, it is not sufficient to inspect the content of
> > > > /etc/ssh/sshd_config
> > > > file,
> > > > because it will not list / contain all the settings that will be
> > > > actually
> > > > applied.
> > > > 
> > > > The only way how to obtain the real settings is to run the "sshd -T"
> > > > command,
> > > > which will print out the real settings. Since in the OVAL checks it is
> > > > not
> > > > possible to run external / arbitrary commands (this limitation is one
> > > > of
> > > > the
> > > > features of the OVAL language), it is not possible within sshd OVAL
> > > > checks
> > > > to run "sshd -T" to obtain final configuration, and therefore it is not
> > > > possible
> > > > reliably to verify if some setting is applied or not (it might be
> > > > applied
> > > > despite not being explicitly present in the /etc/ssh/sshd_config file.
> > > > Like it is the case for the "Protocol 2" default internal setting for
> > > > some
> > > > time already).
> > > > 
> > > > Since we can't inspect the values of internal "default" options, the
> > > > only
> > > > way how
> > > > for sure to tell if the system is configured properly, is to require
> > > > the
> > > > option
> > > > being explicitly present in the /etc/ssh/sshd_config file. In other
> > > > words
> > > > we still
> > > > require the "Protocol 2" directive to be explicitly present in the
> > > > /etc/ssh/sshd_config
> > > > file even when "Protocol 2" internal setting has become "default"
> > > > already
> > > > and it's
> > > > very unlikely some sshd setting would use "Protocol 1" version. The
> > > > obvious
> > > > implication
> > > > of this approach being that the sshd OVAL checks might report false
> > > > negatives in some
> > > > cases (system is configured properly due to the use of safe internal
> > > > "default" value,
> > > > but since the particular option isn't present in /etc/ssh/sshd_config
> > > > [it's
> > > > the sshd's
> > > > default, so it's not necessary to be listed there, since it will be
> > > > used
> > > > anyway],
> > > > we are reporting failure like in the case the system would be
> > > > configured
> > > > improperly).
> > > > 
> > > > There of course is a way how to report proper sshd results - add a new
> > > > <sshd_test>
> > > > probe to the 5.12 version of the OVAL language that would internally
> > > > run
> > > > "sshd -T"
> > > > command when querying sshd options.
> > > > 
> > > > That way we would truly inspect sshd options, that would be really
> > > > applied.
> > > > But
> > > > it is not a short-term solution (it takes time till the proposal is
> > > > accepted into
> > > > OVAL language, it takes time till the new feature is implemented, and
> > > > last
> > > > but not
> > > > least it would work only on those OVAL scanner versions supporting OVAL
> > > > 5.12 language
> > > > versions. IOW till this is implemented, I am afraid we don't have a
> > > > different option,
> > > > just to explicitly require some option to be present in
> > > > /etc/ssh/sshd_config even
> > > > when this might lead to reporting false negatives in some cases).
> > > > 
> > > > > 
> > > > > Any input would be appreciated.
> > > > 
> > > > Hope the above explains the background / motivations behind requiring
> > > > presence
> > > > of an options a bit. FWIW regarding those two reported issues (Ciphers
> > > > check &&
> > > > PermitRootLogin reporting PASS also with '#PermitRootLogin no' setting)
> > > > I
> > > > will
> > > > inspect them yet && report the findings back.
> > > > 
> > > > > 
> > > > > Thanks,
> > > > 
> > > > Thank you && Regards, Jan.
> > > > --
> > > > Jan iankko Lieskovsky / Red Hat Security Technologies Team
> > > > 
> > > > > 
> > > > > Les Kimmel
> > > > > Systems Engineer, CSC
> > > > > 
> > > > > --
> > > > > SCAP Security Guide mailing list
> > > > > scap-security-guide at lists.fedorahosted.org
> > > > > https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
> > > > > https://github.com/OpenSCAP/scap-security-guide/
> > > 
> 


More information about the scap-security-guide mailing list