Page 1 of 1
Bug found in ASL 1.93-3
Posted: Mon Dec 03, 2007 4:31 pm
by aus-city
Scott,
I found a bug in ASL 1.93-3 I have got root login on using passwords. However in my asl.conf I do have this set to yes.
When I run a asl-f it 'fixes' the password auth and root login.
However sometime later when I visit the gui, it shows 2 high alerts, both root login and password auth.
I run a asl-f and it goes away again for a while.
Thanks!
David
Posted: Mon Dec 03, 2007 5:54 pm
by scott
Meaning you disable password authentication in sshd_config and its still reporting it as being enabled?
Posted: Mon Dec 03, 2007 7:08 pm
by aus-city
No, I allow root and password auth, but its marked as being allowed in my asl config
In the last version, as long as you had root login is on and password auth set to on, it would not generate a high alert as they are on in the config file
However now on this new version, I run a asl-f and I have no alerts (as they are on in the config) but later I see there are two high alerts.
Its like something is running automatically in asl and its ignoring that they are yes in the config and therefore should be discarded as an alert.
Sure if you set them off and it finds them on, sure generate an alert, but if you allow it in the config it should not then make an alert later.
All the previous ASL versions obeyed this, but this version is not.
I did put in a email to support about it.
Thanks!
Posted: Tue Dec 04, 2007 10:13 am
by scott
That is expected behavior in this case, since that specific check is both a configuration check and a vulnerability check. The context of the on/off setting is to turn off enforcement in "fix" mode.
The last version of that check had some nasty bugs as I recall, reporting that root logins were allowed when they were in fact not allowed.
There is a methodology in the security world that allows you to accept a risk, which is where you're going with this I think. I honestly only started working out how to build that into the product this morning. Basically the way that would work is that once you have classified the system as a low, moderate, or high security environment you would have the ability to accept a risk based on those criteria.
Some risks you could accept, others are controlled by outside regulators. Like PCI DSS, HIPAA, or GLBA.
Anyway, that involves getting context in first. At this point we can only report the facts.