Matthew N. Wojcik wrote:
> Some of my thoughts on the Debian schema as proposed. Some of these
> also apply to the Red Hat draft on the OVAL Web site.
>
> Regarding inetd:
>
> Is xinetd a commonly used (or bundled) option under Debian, as it is
> under Red Hat?
It is used and supported, but the default superdaemon is inetd. Admins
can replace it but it's not as frequent as in RedHat (where it's the
default). That might (probably) change in the future.
> Parsing xinetd's much more rich and complex
> configuration files is clearly more of a challenge than the
> traditional inetd.conf. Any OVAL schema for these platforms will
> clearly need to take this into consideration.
Agreed.
> Regarding the Debian_Shadow and Debian_Users tables:
>
> This points out to me a mistake I may have made in writing the Solaris
> schema. I swept much of the information in /etc/shadow under the rug
> (and out of the schema) when I made the Solaris_Users table; having a
> "password" field with the "encrypted password from /etc/passwd or
> /etc/shadow" was probably a mistake.
Yes, you are right. Now that I look at it, the Debian_Users should have
the encrypted password in /etc/passwd and the Debian_Shadow the password
from /etc/shadow.
(...)
>
> Another important note: Keith Watson of Cerias (formerly at Sun)
> pointed out to me long ago that the schema notes imply (maybe I should
> say state!) that this information is gathered from these files, rather
> than by using the API calls that also pull data from other sources
> such as NIS(+). I kind of blew this off, since "OVAL's just a
> semantic specification and is not about implementation" (mocking
> self-quote, there), but it's an important point.
Why should it be retrieved from NIS(+)? I mean, if you are running an
OVAL query interpreter you want to determine vulnerabilities in the
local system being tested, not in remote servers. If you want to
determine errors in your NIS(+) configuration you should go to the NIS
server and test there. IMHO. Otherwise you might get inconsistencies in
the way to test for a given vulnerability.
Take CAN-1999-0501 up to CAN-1999-0519, for example. You can test this
checking the password field for UNIX systems that use local
authentication and when using NIS(+) since you can retrieve the remote
map from the NIS server. But what if the system is using
LDAP|Radius|SQL|etc. authentication? Do you have to take all of them
into account in a single query?
> Regarding Debian_Dpkginfo:
>
> I haven't used Debian packages, so forgive my ignorance. Are package
> version and revision numbers well-formed, or are they the typical
> jumble of an arbitrary number of dotted and maybe dashed numbers, with
> things like "p12" or "beta1" thrown in to give everybody headaches?
The correct way for Debian packages is:
[epoch:]upstream_version[-debian_revision]
Upstream_version can contain strings, as described in
http://www.debian.org/doc/debian-policy/ch-versions.htmlbut the conmparison method is very defined.
> See
>
>
http://oval.mitre.org/community/board/archives/2002-07/msg00016.html>
> for some comments on the OVAL Board discussion list last year about
> the difficulty in dealing with these kind of versions. Let me know if
> these concerns apply to Debian packages as well, and/or if anybody has
> any great ideas about how to deal with them. :)
Well, if the issue is with doing comparisons in SQL I would suggest
putting the information into a string and then create stored procedures
(or similar programming stuff, depending on your database of choice) to
compare versions and return the proper result. Of course, in the Debian
case, your could also have these stored procedures to system calls.
Dpkg, for example, can do 'dpkg --compare-versions X op Y' with
different operator 'op' (<, >=, <=, >, = ....)
Would that be a way to solve the issue?
> Regarding Debian_Version:
>
> Basically, the same kind of problem as above, though I assume that
> version numbers for the OS itself are at least somewhat under
> control. Also, Mark Cox advocated using rpm to query for the Red Hat
> release information (rpm -q redhat-release returning something like
> "redhat-release-7.1-1"). Would the information from
> /etc/debian_version show up in our Debian_Dpkginfo table? Should we
> just use that? I don't have anything against having a specific table
> for this file if it's necessary; it's just a question.
I believe it does not make that much sense. And it's better to have them
separated. A query might want to check the debian_version only, and it's
much simpler to have it in a single place than for it to be mixed up
with other package information IMO.
> Regarding Debian_InetdListeningServers:
>
> I fully support the need to determine if a service is truly running
> under our "Vulnerable Configuration" portion of OVAL queries. The
> fact that netstat information can be bound to process ID/name directly
> under Linux is a big advantage that we should take advantage of.
Agreed, I did follow the discussions on this back in January (related to
CAN-2002-0763) and I'm on the same opinion as you. One thing is having
vulnerable software installed, and another one is being remotely
exploitable because that software is running.
>
> Having said that, I just took a quick look at the output of
> netstat -tuwlnpe and netstat -tuwlnpea on my Red Hat box at home, and
> I'd need to investigate it a lot more before I was comfortable using
> it in a query. The problem once again is inetd / xinetd: I'm more
> confident that a vulnerable in.ftpd binary is going to be answering
> incoming client requests if I know that inetd or xinetd is running and
> configured to run that binary, than I am if I only see that (x)inetd is
> listening on port 21, ready to respond to a client request by
> launching *something*. Does that make sense?
Yes. In the case of (x)inetd is the 'super-server' is the one in charge
of opening the port so you will only see that process for all services
handled by it (i.e. for all in 'grep -v ^# /etc/inetd.conf'). A query
that wants to determine if your ftp server is vulnerable you have to
a) check if the ftp server binary and related libraries are vulnerable
b) check if inetd is configured to run it at a given port
c) check if either the server itself is listening or inetd is listening
on the port determined in b)
The funny thing is that if inetd handles the service it's easier to
detect if you have a vulnerable service/server than when the service is
opening the port directly. That's because you have, not only to check
the files and libraries of server installed but also of the server that
is running. I.e. if the server was not restarted after a patch was
applied to the binaries (or its libraries) it will still be vulnerable.
And that's not that easy to check.
> This may just be because I'm not familiar enough with my options under
> GNU/Linux. But I do think there's an important point there. Perhaps
> Javier or others could explain more about the concern with the current
> OVAL approach. Maybe give an example of a scenario where that
> approach would fail?
Yes, given the scenario above (vendor patches applied but the server has
not been restarted) the following queries will fail: OVAL94, OVAL56,
OVAL15, OVAL11 and OVLA9. Note that the "AND NOT EXISTS Patch XXXX-XX"
will return a false negative in this scenario. So, in all remote
exploitable flaws you have to check, not only that the patch is applied
(either by looking at the patches applied in Solaris or the versions
installed in RedHat or Debian, or comparing MD5sums in either of them)
but that the running service is using the same binary than the one is
now on the system.
> I want to be clear that I'm not just trying to shoot down any proposed
> changes to the way OVAL has been going about detecting
> vulnerabilities. :) I'm just not sure I fully understand the issue.
>
Brian Hatch talked about this (probably explaining it better than me)
recently in "Linux Security: Tips, Tricks, and Hackery" mailing list,
online available at
http://www.hackinglinuxexposed.com/articles/20030409.html> Many thanks to Javier for the work he has put in, and for getting work
> on OVAL support for GNU/Linux (re)started.
You are most welcome, I should have sent this a long time ago.
Regards
Javier
