tech-security archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: about vulnerabilities without advisories: how to keep informed



Hi,

semarie-netbsd%latrappe.fr@localhost (Frère Sébastien Marie) writes:

>I have noted that severals vulnerabilities are corrected in NetBSD release 
>branchs but without any advisories.

>http://www.netbsd.org/support/security/ mention advisories for "serious 
>security problems", but how keep informed about others security problems ?

Since noone else is picking this up ..

Issues where root would need to run a problematic binary usually fall
below the 'needs an advisory' threshold, as do problems that need a rather
unusual configuration to bite. Another threshold is vulnerabilities
in HEAD only: these get fixed, but no advisory.

>Here a list from NetBSD-5-0 branch (taken from src/doc/CHANGES-5.0.3), in 
>order to flag the problem.

>Please notie that all of these are currently without advisories, so are not 
>"serious security problems" (or perhaps advisory process is engaged... but all 
>are more 12 day old)

>* CVE-2011-0997 [spz, ticket #1595], Thu Apr 7 17:25:47 2011 UTC
>  dhclient in ISC DHCP 3.0.x through 4.2.x before 4.2.1-P1, 3.1-ESV before 
> 3.1-ESV-R1, and 4.1-ESV before 4.1-ESV-R2 allows remote attackers to execute 
> arbitrary commands via shell metacharacters in a hostname obtained from a 
> DHCP message.
>  CVSS v2 Base Score:7.5 (HIGH) [from nvd.nist.gov]  

This should get an advisory yet.

>* CVE-2011-0465 [mrg, ticket #1594], Thu Apr 7 06:56:25 2011 UTC
>  xrdb.c in xrdb before 1.0.9 in X.Org X11R7.6 and earlier allows remote 
> attackers to execute arbitrary commands via shell metacharacters in a 
> hostname obtained from a (1) DHCP or (2) XDMCP message
>  CVSS v2 Base Score:9.3 (HIGH) [from nvd.nist.gov]

This requires the hostname to be something nasty. With the "nasty hostname
via dhcp" hole plugged, this changes into the class "root attacking their
users".

>* unassigned-CVE [christos, ticket #1593], Tue Apr 5 06:23:12 2011 UTC
>  "Protect against stack smashes."
>  so should be have security consideration, according to the description, and 
> to the fact changes are pull-up in release branch

Christos will have to comment on that.

>* unassigned-CVE [spz, ticket #1586], Tue Mar 29 20:13:51 2011 UTC
>  "Clean up setting ECN bit in TOS.  Fixes PR 44742"
>  PR/44742: "Remotely triggerable ECN panic in tcp_output()"
>  so is a remote-dos (under particular circonstances ?)

The feature is off by default in NetBSD-5, and a bit convoluted to enable.

>* CVE-2011-0411 [tron, ticket #1578], Thu Mar 24 20:11:25 2011 UTC
>  The STARTTLS implementation in Postfix 2.4.x before 2.4.16, 2.5.x before 
> 2.5.12, 2.6.x before 2.6.9, and 2.7.x before 2.7.3 does not properly restrict 
> I/O buffering, which allows man-in-the-middle attackers to insert commands 
> into encrypted SMTP sessions by sending a cleartext command that is processed 
> after TLS is in place, related to a "plaintext command injection" attack.
>  CVSS v2 Base Score:6.8 (MEDIUM) [from nvd.nist.gov]

>(not exhaustive list: see 
>http://cvsweb.netbsd.org/bsdweb.cgi/src/doc/Attic/CHANGES-5.0.3 )

The impact of the vulnerability is too low given that the default config
is less secure than TLS with the vulnerability.

>There also security issue known and corrected in current, but not pulled in 
>release branch:

>* CVE-2011-996 [roy 20110406], Wed Apr 6 09:11:08 2011 UTC
>  import dhcpcd-5.2.12
>  dhcpcd before 5.2.12 allows remote attackers to execute arbitrary commands 
> via shell metacharacters in a hostname obtained from a DHCP message
>  CVSS v2 Base Score:6.8 (MEDIUM) [from nvd.nist.gov]

That's not a vulnerability in dhcpcd, but in scripts that may use the
hostname naively, and basically the same issue as with CVE-2011-997, only
that with dhclient the first script that sees the naughty hostname is part
of dhclient itself. I'm preparing a pullup for netbsd-5 but am not done
yet.

>In conclusion, how to keep informed of current issues of the base system ?
>I think something like audit-packages (for pkgsrc), or a website like 
>security-tracker.debian.org (for debian) ?

I doubt that adding even more work for the few people who look after
security issues will speed anything up.

>Currently, I follow any changes in src/doc/CHANGES-xxx , but as flagged with 
>dhcpcd, known issues still exist in release branch. I hope pullup process is 
>engaged, but how to check this ?

http://releng.netbsd.org/

regards,
        spz
-- 
spz%serpens.de@localhost (S.P.Zeidler)


Home | Main Index | Thread Index | Old Index