security issues in ports: portaudit and VuXML (was: Re: security
issues in Ports and VuXML)
Ion-Mihai Tetcu
itetcu at apropo.ro
Fri Feb 13 01:48:17 PST 2004
On Fri, 13 Feb 2004 02:36:28 +0100
Oliver Eikemeier <eikemeier at fillmore-labs.com> wrote:
> I appreciate every contribution or feedback that helps us to bring
> portaudit and VuXML to an 1.0 status.
Since you've asked for it ;)
> Ion-Mihai Tetcu wrote:
>
> > On Thu, 12 Feb 2004 08:45:22 -0600
> > "Jacques A. Vidrine" <nectar at FreeBSD.org> wrote:
> >
> >>Hello Porters!
> >>
> >>If you know of security issues for ports that you maintain,
> >>please make an effort to include those issues in the VuXML file
> >>(ports/security/vuxml/vuln.xml). You can either use existing
> >entries>as examples, or if you are completely lost you can just email
> >>security-team at FreeBSD.org with your information.
> >
> > What is the relation between this and ports/security/portaudit which
> > has been recently added to the ports infrastructure ?
>
> Both port deal with known security vulnerabilities in the FreeBSD
> system: VuXML is a generic database format for the whole system
> including the base system, portaudit a framework to check if a FreeBSD
> port is listed in a vulnerability database, including a more stringent
> version number definition, a database distribution system and checking
> during install time.
>
> As far as I understand the focus of portaudit and VuXML, they are
> complementing projects.
>
> In the current state portaudit uses a simple flat file database since
> I needed something to start with and wanted a format that is common to
> port committers(similar to MOVED), but the system is more or less
> database format agnostic. Because the distribution file is a simple
> tar file it is easy to distribute the VuXML database along with the
> flat file database, or even add signatures.
>
> If we decide that the VuXML format is better suited for the job than a
> flat file database it is easy to integrate it into portaudit in the
> long run, I have to look into security/vuxml to see what is the best
> way to synchronize the databases.
I suggest it's now the time to do that. Both ideas are good, but keeping
to different databases means updating to different files, which means
they would get out of sync. See the example on the end.
> It is great to see security-team@ support for port security auditing,
Yup, it's a long awaited feature.
> and I like to involve more people in the project.
wc -l on this email = 248 :)
> Currently portaudit is in a development and learning phase, and issues
> I'm working on are:
>
> - a better distribution system, e.g. a script that finds the nearest
> mirror of the database and fetches the file from there, not from a
> random location, integrating PR 62655.
> - a checksum system the checks if a new database is available by just
> fetching a md5 sum or a date and not the whole database, like the way
> clamav does it.
;) The idea came when I've exhausted my bandwidth with other traffic and
a nice three screens cron email came in with "fetch: timeout ..". I'm
not at all happy with fetch, which fails more often that it should ,
although DES's recent commit improves it it a lot.
I vote for (at least) md5. If someone manages to screw his local
database this will assure it is corrected on the first run.
An other idea would be using cvsup against
security/portaudit/database/auditfile.txt, since the dailly changes are
not big. So we could have:
daily_status_portaudit_enable="YES|NO"
${portaudit_update_method:="all"} # one of: "cvsup | ftp | llocal | all"
${portaudit_update_preferred_method_order:="local cvsup ftp"}
portaudit_LOCATIONS_overrride="{ftp|www}.my.preferred.host"
portaudit_cvsup_host="cvsup.my.preferred.host"
On portaudit_update_method="all" it will go something like this:
1. DB_md5 = md5 of the current database
2. DB_VER = version ($FreeBSD: ...) of the
current database.
3. PORT_DB_VER = version (($FreeBSD: ....) of the
/usr/ports/security/portaudit/database/auditfile.txt
4. MASTER_DB_MD5 = md5 check on net
6. MASTER_DB_VER = MASTER_DB_CVS_VER = version ($FreeBSD: ....) of the
${portaudit_file} on net
5. something like:
if [ ! "$MASTER_DB_MD5" = "$DB_MD5"]
then
if [ ! "$PORT_DB_VER" = "$MASTER_DB_VER" ]
then
# problem: what if the file is changed between assigning
# MASTER_DB_MD5 and ftp/cvsup
until [ $TEMP_DB_MD5 = MASTER_DB_MD5 ]
do
// get the update in portaudit_update_preferred_method_order
// check again the md5
//....
done
else
// copy the file from
/usr/ports/security/portaudit/database/auditfile.txt
fi
else
echo "Database already up-to-date"
fi
The "local" idea: if you cvsup daily you probably have the right
database in ports.
Shouldn't security/portaudit/database/auditfile.txt atualy be
security/portaudit/database/auditfile.tbz ? Or better yet
DISTFILES=auditfile.tbz
How does it look ? Write and send patch ?
> - a push mechanism that informs systems (by email?) that an updated
> database is available instead of waiting for the next scheduled check.
Store somewhere DB_md5 and check once an hour. I don't see how it can be
done by email (or any other push); I have servers that do not receive
emails. On the other hand the email should be gpg signed (and this
complicates the hole thing) as the email To: address will be public so
anyone could nicely bomb portaudit_updates at my.domain
> - integration of the system into pkg_add of sysutils/pkg_install-devel
It would be nice, indeed.
> - a flat file -> VuXML converter. That should be easy.
>
> - an evaluation if it makes sense to integrate expat based tools in
> the periodic and bsd.port.mk check, or if it is better to convert to
> VuXML database for distribution.
>
> - a VuXML -> flat file converter, to see how it fits into the
> structure. One thing that can be problematic here is the copyright
> notice, because it makes most XML tools hard to use.
Flat file please, it's easier to use by hand on console. Use VuXML
database to generate the master flat file. Make everybody do updates on
VuXML, as is more complete and generate portaudit's database from it.
Eventually integrate the converter in VuXM, no need to complicare
bsd.port.mk.
Example::
> VuXML:
<vuln vid="6fd02439-5d70-11d8-80e3-0020ed76ef5a">
<topic>Several remotely exploitable buffer overflows in gaim</topic>
<affects>
<package>
<name>gaim</name>
<range><lt>0.75_3</lt></range>
<range><eq>0.75_5</eq></range>
</package>
</affects>
<description>
<body xmlns="http://www.w3.org/1999/xhtml">
<p>Stefan Esser of e-matters found almost a dozen remotely
exploitable vulnerabilities in Gaim. From the e-matters
advisory:</p>
<blockquote cite="http://security.e-matters.de/advisories/012004.txt">
<p>While developing a custom add-on, an integer overflow
in the handling of AIM DirectIM packets was revealed that
could lead to a remote compromise of the IM client. After
disclosing this bug to the vendor, they had to make a
hurried release because of a change in the Yahoo connection
procedure that rendered GAIM useless. Unfourtunately at the
same time a closer look onto the sourcecode revealed 11 more
vulnerabilities.</p>
<p>The 12 identified problems range from simple standard
stack overflows, over heap overflows to an integer overflow
that can be abused to cause a heap overflow. Due to the
nature of instant messaging many of these bugs require
man-in-the-middle attacks between client and server. But the
underlying protocols are easy to implement and MIM attacks
on ordinary TCP sessions is a fairly simple task.</p>
<p>In combination with the latest kernel vulnerabilities or
the habit of users to work as root/administrator these bugs
can result in remote root compromises.</p>
</blockquote>
</body>
</description>
<references>
<url>http://security.e-matters.de/advisories/012004.txt</url>
<cvename>CAN-2004-0005</cvename>
<cvename>CAN-2004-0006</cvename>
<cvename>CAN-2004-0007</cvename>
<cvename>CAN-2004-0008</cvename>
</references>
<dates>
<discovery>2004/01/26</discovery>
<entry>2004/02/12</entry>
</dates>
</vuln>
> portaudit:
gaim<0.75_2|http://security.e-matters.de/advisories/012004.txt|12
vulnerabilities that allow remote compromise
What should i trust :
<range><lt>0.75_3</lt></range>
<range><eq>0.75_5</eq></range>
vs.
gaim<0.75_2
As a note, in VuXML the
<package>
<name>gaim</name>
should be something like:
<package>
<name>$UNIQUENAME</name>
<port>net/gaim</port>
<alternate>virtual category here</alternate>
<name_vendor></name_vendor>
e.g. listing also the name the ports way. I might be wrong here, but I
think it is easier for users this way, as VuXML is primary a "visual
tool" . I would also include the virtual categories the port belongs to,
for the ease of use. It might be also useful to list in VuXML the
original (vendor) name_and_version of the package being vulnerable, as
we have:
1. PKGNAMEPREFIX, PORTNAME, PKGNAMESUFFIX, PORTVERSION,
PORTEPOCH and matching "our" package with the rest of the world could be
sometime very time-consuming, esp. for newbies.
2. we my have patches for a vendor's version so our
PORTVERSION_PORTREVISION is ok.
3. we may have a vulnerability not present on other platforms for the
same vendor version.
4. our package may not be vulnerable, but on other platforms the same
vendor version is (should we have an entry in this case ?).
> That includes keeping ports/security/portaudit/database/auditfile.txt
> and ports/security/vuxml/vuln.xml up to date, since this is the only
> way we can test and improve the system to bring it closer to a release
> status.
Some random thoughts:
1. a ports-security-team at FreeBSD.org to make base system vs. ports
vulnerabilities clear. Now in worse case scenario you have to search the
prs body.
2. a category / class in GNATS for security prs and / or additions to
the database. We have ports with long maintainer feedback timeout and
with the generic ports@ maintainer. As everyone could submit to the
database this will help peoples with commit bits. Second, this will
force people to submit security related prs by their own, not with other
patches. Of course, I might be totally wrong here.
--
IOnut
Unregistered ;) FreeBSD user
More information about the freebsd-ports
mailing list