Author: kees
Date: 2009-04-17 01:25:52 +0000 (Fri, 17 Apr 2009)
New Revision: 11636
Modified:
data/CVE/list
Log:
Sync from Ubuntu CVE tracker...
unfixed: archivemail azureus clamav evolution-data-server ghostscript
graphicsmagick iceape iceweasel jbossas4 libapache2-mod-perl2 libstruts1.2-java
linux-2.6 ntp openjdk-6 python2.4 python2.5 sun-java5 sun-java6 tomcat5.5
torrentflux typo3-src wireshark xulrunner
fixed: lighttpd tunapie
Modified: data/CVE/list
==================================================================---
data/CVE/list 2009-04-16 21:14:13 UTC (rev 11635)
+++ data/CVE/list 2009-04-17 01:25:52 UTC (rev 11636)
@@ -163,15 +163,15 @@
- php4 <not-affected> (the JSON extension was introduced in php5.2)
- php-json-ext <unfixed>
CVE-2009-1269 (Unspecified vulnerability in Wireshark 0.99.6 through 1.0.6
allows ...)
- TODO: check
+ - wireshark <unfixed>
CVE-2009-1268 (The Check Point High-Availability Protocol (CPHAP) dissector in
...)
- TODO: check
+ - wireshark <unfixed>
CVE-2009-1267 (Unspecified vulnerability in the LDAP dissector in Wireshark
0.99.2 ...)
- TODO: check
+ - wireshark <unfixed>
CVE-2009-1266
RESERVED
CVE-2009-1265 (Integer overflow in rose_sendmsg (sys/net/af_rose.c) in the
Linux ...)
- TODO: check
+ - linux-2.6 <unfixed>
CVE-2009-1264 (Frontend User Registration (sr_feuser_register) extension 2.5.20
and ...)
NOT-FOR-US: Frontend User Registration (sr_feuser_register) extension
CVE-2009-1263 (SQL injection vulnerability in sub_commententry.php in the
BookJoomlas ...)
@@ -193,7 +193,7 @@
CVE-2009-1255
RESERVED
CVE-2008-6679 (Buffer overflow in the BaseFont writer module in Ghostscript
8.62, and ...)
- TODO: check
+ - ghostscript <unfixed>
CVE-2008-6678 (SQL injection vulnerability in asp/includes/contact.asp in
QuickerSite ...)
NOT-FOR-US: QuickerSite
CVE-2008-6677 (Unrestricted file upload vulnerability in ...)
@@ -239,7 +239,7 @@
CVE-2008-6657 (Cross-site request forgery (CSRF) vulnerability in index.php in
Simple ...)
NOT-FOR-US: Simple Machines Forum
CVE-2007-6725 (The CCITTFax decoding filter in Ghostscript 8.60, 8.61, and
possibly ...)
- TODO: check
+ - ghostscript <unfixed>
CVE-2009-XXXX [roundup: insufficient access checks in web frontend]
- roundup <unfixed> (bug #518768)
[etch] - roundup 1.2.1-10+etch1
@@ -259,10 +259,10 @@
- clamav 0.94.dfsg.2-1~volatile2 (medium; bug #523016)
CVE-2009-1254 (James Stone Tunapie 2.1 allows remote attackers to execute
arbitrary ...)
{DSA-1764-1}
- TODO: check
+ - tunapie 2.1.17-1
CVE-2009-1253 (James Stone Tunapie 2.1 allows local users to overwrite
arbitrary ...)
{DSA-1764-1}
- TODO: check
+ - tunapie 2.1.17-1
CVE-2009-1252
RESERVED
CVE-2009-1251 (Heap-based buffer overflow in the cache manager in the client in
...)
@@ -360,7 +360,7 @@
CVE-2008-6622 (SQL injection vulnerability in choosecard.php in WEBBDOMAIN Post
Card ...)
NOT-FOR-US: WEBBDOMAIN Multi Languages WebShop Online
CVE-2008-6621 (Unspecified vulnerability in GraphicsMagick before 1.2.3 allows
remote ...)
- TODO: check
+ - graphicsmagick <unfixed>
CVE-2008-6620 (Multiple cross-site scripting (XSS) vulnerabilities in ...)
NOT-FOR-US: GraFX miniCWB
CVE-2008-6619 (Unrestricted file upload vulnerability in class/ApplyDB.php in
...)
@@ -421,7 +421,7 @@
CVE-2008-6595 (SQL injection vulnerability in the pmk_rssnewsexport extension
for ...)
NOT-FOR-US: pmk_rssnewsexport extension for TYPO3
CVE-2008-6594 (SQL injection vulnerability in the cm_rdfexport extension for
TYPO3 ...)
- TODO: check
+ - typo3-src <unfixed>
CVE-2008-6593 (SQL injection vulnerability in LightNEasy/lightneasy.php in
LightNEasy ...)
NOT-FOR-US: LightNEasy SQLite
CVE-2008-6592 (thumbsup.php in Thumbs-Up 1.12, as used in LightNEasy
"no database" ...)
@@ -435,13 +435,13 @@
CVE-2008-6588 (Aztech ADSL2/2+ 4-port router has a default
"isp" account with a ...)
NOT-FOR-US: Aztech port router
CVE-2008-6587 (Cross-site request forgery (CSRF) vulnerability in index.tmpl in
Vuze ...)
- TODO: check
+ - azureus <unfixed>
CVE-2008-6586 (Cross-site request forgery (CSRF) vulnerability in gui/index.php
in ...)
NOT-FOR-US: ?Torrent (uTorrent) WebUI
CVE-2008-6585 (Cross-site request forgery (CSRF) vulnerability in
html/admin.php in ...)
- TODO: check
+ - torrentflux <unfixed>
CVE-2008-6584 (html/index.php in TorrentFlux 2.3 allows remote authenticated
users to ...)
- TODO: check
+ - torrentflux <unfixed>
CVE-2008-6583 (Buffer overflow in BS.player 2.27 build 959 allows remote
attackers to ...)
NOT-FOR-US: BS.player
CVE-2009-1274 (Integer overflow in the qt_error parse_trak_atom function in
...)
@@ -1859,16 +1859,16 @@
CVE-2009-0797
RESERVED
CVE-2009-0796 (Cross-site scripting (XSS) vulnerability in Status.pm in ...)
- TODO: check
+ - libapache2-mod-perl2 <unfixed>
CVE-2009-0795 [af_rose/x25 DoS]
REJECTED
- linux-2.6 <unfixed>
- linux-2.6.24 <unfixed>
CVE-2009-0794 (Integer overflow in the PulseAudioTargetDataL class in ...)
- TODO: check
+ - openjdk-6 <unfixed>
CVE-2009-0793 (cmsxform.c in LittleCMS (aka lcms or liblcms) 1.18, as used in
OpenJDK ...)
{DSA-1769-1}
- TODO: check
+ - openjdk-6 <unfixed>
CVE-2009-0792 (Multiple integer overflows in icc.c in the International Color
...)
- argyll <unfixed> (low; bug #523427)
CVE-2009-0791
@@ -2445,7 +2445,9 @@
CVE-2009-0653 (OpenSSL, probably 0.9.6, does not verify the Basic Constraints
for an ...)
- openssl 0.9.8-1 (bug #517791)
CVE-2009-0652 (Mozilla Firefox 3.0.6 does not properly prevent the literal
rendering ...)
- TODO: check
+ - iceape <unfixed>
+ - xulrunner <unfixed>
+ - iceweasel <unfixed>
CVE-2009-0651 (Unspecified vulnerability in the Veritas network daemon (aka
vnetd) in ...)
NOT-FOR-US: Veritas network daemon
CVE-2009-0650 (Stack-based buffer overflow in the GetStatsFromLine function in
TPTEST ...)
@@ -2924,7 +2926,7 @@
- gs-gpl <removed>
- gs-esp <removed>
CVE-2009-0582 (The ntlm_challenge function in the NTLM SASL authentication
mechanism ...)
- TODO: check
+ - evolution-data-server <unfixed>
CVE-2009-0581 (Memory leak in LittleCMS (aka lcms or liblcms) before 1.18beta2,
as ...)
{DSA-1769-1 DSA-1745-1}
- lcms 1.18.dfsg-1 (bug #522446)
@@ -3405,11 +3407,11 @@
CVE-2008-6073 (StorageCrypt 2.0.1 does not properly encrypt disks, which allows
local ...)
NOT-FOR-US: StorageCrypt
CVE-2008-6072 (Multiple unspecified vulnerabilities in GraphicsMagick before
1.1.14, ...)
- TODO: check
+ - graphicsmagick <unfixed>
CVE-2008-6071 (Heap-based buffer overflow in the DecodeImage function in ...)
- TODO: check
+ - graphicsmagick <unfixed>
CVE-2008-6070 (Multiple heap-based buffer underflows in the ReadPALMImage
function in ...)
- TODO: check
+ - graphicsmagick <unfixed>
CVE-2008-6069 (SQL injection vulnerability in e107chat.php in the eChat plugin
4.2 ...)
NOT-FOR-US: eChat plugin
CVE-2008-6068 (SQL injection vulnerability in the JoomlaDate (com_joomladate)
...)
@@ -3996,7 +3998,8 @@
- dia 0.96.1-7.1 (low; bug #504251)
[etch] - dia <no-dsa> (Minor issue, only vulnerable when called from
certain dir)
CVE-2008-5983 (Untrusted search path vulnerability in the PySys_SetArgv API
function ...)
- TODO: check
+ - python2.5 <unfixed>
+ - python2.4 <unfixed>
CVE-2008-5982 (Format string vulnerability in BMC PATROL Agent before 3.7.30
allows ...)
NOT-FOR-US: BMC PATROL Agent
CVE-2009-0323 (Multiple stack-based buffer overflows in W3C Amaya Web Browser
10.0 ...)
@@ -4313,7 +4316,7 @@
CVE-2009-0197 (Integer overflow in the FORMATS Plugin before 4.23 for IrfanView
...)
NOT-FOR-US: IrfanView
CVE-2009-0196
- RESERVED
+ - ghostscript <unfixed>
CVE-2009-0195
RESERVED
CVE-2009-0194
@@ -4414,7 +4417,7 @@
CVE-2009-0160
RESERVED
CVE-2009-0159 (Stack-based buffer overflow in the cookedprint function in
ntpq/ntpq.c ...)
- TODO: check
+ - ntp <unfixed>
CVE-2009-0158
RESERVED
CVE-2009-0157
@@ -5409,7 +5412,7 @@
- linux-2.6 2.6.29-1
- linux-2.6.24 <unfixed>
CVE-2009-0027 (The request handler in JBossWS in JBoss Enterprise Application
...)
- TODO: check
+ - jbossas4 <unfixed>
CVE-2009-0026 (Multiple cross-site scripting (XSS) vulnerabilities in Apache
...)
NOT-FOR-US: Apache Jackrabbit
CVE-2009-0025 (BIND 9.6.0, 9.5.1, 9.5.0, 9.4.3, and earlier does not properly
check ...)
@@ -5602,7 +5605,7 @@
CVE-2008-5526 (DrWeb Anti-virus 4.44.0.09170, when Internet Explorer 6 or 7 is
used, ...)
NOT-FOR-US: DrWeb Anti-virus
CVE-2008-5525 (ClamAV 0.94.1 and possibly 0.93.1, when Internet Explorer 6 or 7
is ...)
- TODO: check
+ - clamav <unfixed>
NOTE: CVE claims it only happens when Internet Explorer 6 or 7 is used, but
ClamAV doesn''t have any special code for IE
CVE-2008-5524 (CAT-QuickHeal 10.00 and possibly 9.50, when Internet Explorer 6
or 7 ...)
NOT-FOR-US: CAT-QuickHeal
@@ -5615,7 +5618,7 @@
CVE-2008-5520 (AhnLab V3 2008.12.4.1 and possibly 2008.9.13.0, when Internet
Explorer ...)
NOT-FOR-US: AhnLab V3
CVE-2008-5519 (The JK Connector (aka mod_jk) 1.2.0 through 1.2.26 in Apache
Tomcat ...)
- TODO: check
+ - tomcat5.5 <unfixed>
CVE-2008-5518
RESERVED
CVE-2008-5517 (The web interface in git (gitweb) 1.5.x before 1.5.6 allows
remote ...)
@@ -7641,7 +7644,9 @@
NOTE: not reproducible using iceweasel 3.0.1
CVE-2008-4723 (Multiple cross-site scripting (XSS) vulnerabilities in Mozilla
Firefox ...)
{CVE-2008-4724}
- TODO: check
+ - iceape <unfixed>
+ - xulrunner <unfixed>
+ - iceweasel <unfixed>
NOTE: http://www.jorgan.users.cg.yu/ seems to be the original source
NOTE: Not enough details to tell if this is a real vulnerability.
NOTE: My guess is that file names containing <>& are incorrectly
@@ -13994,7 +13999,9 @@
CVE-2008-2087 (SQL injection vulnerability in search_result.php in Softbiz Web
Host ...)
NOT-FOR-US: Softbiz Web Host Directory Script
CVE-2008-2086 (Sun Java Web Start and Java Plug-in for JDK and JRE 6 Update 10
and ...)
- TODO: check
+ - openjdk-6 <unfixed>
+ - sun-java5 <unfixed>
+ - sun-java6 <unfixed>
CVE-2008-2084 (SQL injection vulnerability in topics.php in the MyArticles 0.6
beta-1 ...)
NOT-FOR-US: MyArticles
CVE-2008-2083 (SQL injection vulnerability in directory.php in Prozilla Hosting
...)
@@ -14121,7 +14128,7 @@
CVE-2008-2026 (Cross-site scripting (XSS) vulnerability in
WebID/IISWebAgentIF.dll in ...)
NOT-FOR-US: RSA Authentication Agent
CVE-2008-2025 (Cross-site scripting (XSS) vulnerability in Apache Struts before
...)
- TODO: check
+ - libstruts1.2-java <unfixed>
CVE-2008-2024 (Cross-site scripting (XSS) vulnerability in index.php in miniBB
2.2, ...)
NOT-FOR-US: miniBB
CVE-2008-2023 (Multiple SQL injection vulnerabilities in PD9 Software MegaBBS
2.2 ...)
@@ -29267,7 +29274,7 @@
CVE-2007-2842
RESERVED
CVE-2007-2841 [lighttpd DoS]
- RESERVED
+ - lighttpd 1.4.16-1 (bug #428368)
NOTE: Duplicate of CVE-2007-3947, was assigned from Debian CNA and clashed
with MITRE
NOTE: assignment
CVE-2007-2840
@@ -42623,7 +42630,7 @@
{DSA-1177-1}
- usermin <removed> (bug #374609)
CVE-2006-4245
- RESERVED
+ - archivemail <unfixed>
CVE-2006-4244 (SQL-Ledger 2.4.4 through 2.6.17 authenticates users by verifying
that ...)
{DSA-1239-1}
- sql-ledger 2.6.18-1 (medium; bug #386519)
@@ -45262,7 +45269,6 @@
{DSA-1112}
- mysql-dfsg-5.0 5.0.19-1 (bug #373913; high)
CVE-2006-3100 [termnetd buffer overflow]
- RESERVED
- termpkg 3.3-7 (bug #358028; medium)
CVE-2006-3085 (xt_sctp in netfilter for Linux kernel before 2.6.17.1 allows
attackers ...)
- linux-2.6 2.6.16-15
would it make sense to integrate ubuntu''s security tracker with debian''s, especially since the two distros are so closely related? for example, [intrepid]/[jaunty] tags could be used to track ubuntu-specific issues within the debian tracker. this would greatly reduce duplication of effort and make it clear to the other team when the one pushes a fix since everyone will be getting updates from the same tracker. it would also make a lot of sense for the two teams to work more closely together. also, debsecan could finally be modified so that its output makes sense on ubuntu (a pet peeve of mine). just a thought. mike On Fri, 17 Apr 2009 01:25:52 +0000 Kees Cook <kees at alioth.debian.org> wrote:> Author: kees > Date: 2009-04-17 01:25:52 +0000 (Fri, 17 Apr 2009) > New Revision: 11636 > > Modified: > data/CVE/list > Log: > Sync from Ubuntu CVE tracker... > unfixed: archivemail azureus clamav evolution-data-server ghostscript graphicsmagick iceape iceweasel jbossas4 libapache2-mod-perl2 libstruts1.2-java linux-2.6 ntp openjdk-6 python2.4 python2.5 sun-java5 sun-java6 tomcat5.5 torrentflux typo3-src wireshark xulrunner > fixed: lighttpd tunapie > > > Modified: data/CVE/list > ==================================================================> --- data/CVE/list 2009-04-16 21:14:13 UTC (rev 11635) > +++ data/CVE/list 2009-04-17 01:25:52 UTC (rev 11636) > @@ -163,15 +163,15 @@ > - php4 <not-affected> (the JSON extension was introduced in php5.2) > - php-json-ext <unfixed> > CVE-2009-1269 (Unspecified vulnerability in Wireshark 0.99.6 through 1.0.6 allows ...) > - TODO: check > + - wireshark <unfixed> > CVE-2009-1268 (The Check Point High-Availability Protocol (CPHAP) dissector in ...) > - TODO: check > + - wireshark <unfixed> > CVE-2009-1267 (Unspecified vulnerability in the LDAP dissector in Wireshark 0.99.2 ...) > - TODO: check > + - wireshark <unfixed> > CVE-2009-1266 > RESERVED > CVE-2009-1265 (Integer overflow in rose_sendmsg (sys/net/af_rose.c) in the Linux ...) > - TODO: check > + - linux-2.6 <unfixed> > CVE-2009-1264 (Frontend User Registration (sr_feuser_register) extension 2.5.20 and ...) > NOT-FOR-US: Frontend User Registration (sr_feuser_register) extension > CVE-2009-1263 (SQL injection vulnerability in sub_commententry.php in the BookJoomlas ...) > @@ -193,7 +193,7 @@ > CVE-2009-1255 > RESERVED > CVE-2008-6679 (Buffer overflow in the BaseFont writer module in Ghostscript 8.62, and ...) > - TODO: check > + - ghostscript <unfixed> > CVE-2008-6678 (SQL injection vulnerability in asp/includes/contact.asp in QuickerSite ...) > NOT-FOR-US: QuickerSite > CVE-2008-6677 (Unrestricted file upload vulnerability in ...) > @@ -239,7 +239,7 @@ > CVE-2008-6657 (Cross-site request forgery (CSRF) vulnerability in index.php in Simple ...) > NOT-FOR-US: Simple Machines Forum > CVE-2007-6725 (The CCITTFax decoding filter in Ghostscript 8.60, 8.61, and possibly ...) > - TODO: check > + - ghostscript <unfixed> > CVE-2009-XXXX [roundup: insufficient access checks in web frontend] > - roundup <unfixed> (bug #518768) > [etch] - roundup 1.2.1-10+etch1 > @@ -259,10 +259,10 @@ > - clamav 0.94.dfsg.2-1~volatile2 (medium; bug #523016) > CVE-2009-1254 (James Stone Tunapie 2.1 allows remote attackers to execute arbitrary ...) > {DSA-1764-1} > - TODO: check > + - tunapie 2.1.17-1 > CVE-2009-1253 (James Stone Tunapie 2.1 allows local users to overwrite arbitrary ...) > {DSA-1764-1} > - TODO: check > + - tunapie 2.1.17-1 > CVE-2009-1252 > RESERVED > CVE-2009-1251 (Heap-based buffer overflow in the cache manager in the client in ...) > @@ -360,7 +360,7 @@ > CVE-2008-6622 (SQL injection vulnerability in choosecard.php in WEBBDOMAIN Post Card ...) > NOT-FOR-US: WEBBDOMAIN Multi Languages WebShop Online > CVE-2008-6621 (Unspecified vulnerability in GraphicsMagick before 1.2.3 allows remote ...) > - TODO: check > + - graphicsmagick <unfixed> > CVE-2008-6620 (Multiple cross-site scripting (XSS) vulnerabilities in ...) > NOT-FOR-US: GraFX miniCWB > CVE-2008-6619 (Unrestricted file upload vulnerability in class/ApplyDB.php in ...) > @@ -421,7 +421,7 @@ > CVE-2008-6595 (SQL injection vulnerability in the pmk_rssnewsexport extension for ...) > NOT-FOR-US: pmk_rssnewsexport extension for TYPO3 > CVE-2008-6594 (SQL injection vulnerability in the cm_rdfexport extension for TYPO3 ...) > - TODO: check > + - typo3-src <unfixed> > CVE-2008-6593 (SQL injection vulnerability in LightNEasy/lightneasy.php in LightNEasy ...) > NOT-FOR-US: LightNEasy SQLite > CVE-2008-6592 (thumbsup.php in Thumbs-Up 1.12, as used in LightNEasy "no database" ...) > @@ -435,13 +435,13 @@ > CVE-2008-6588 (Aztech ADSL2/2+ 4-port router has a default "isp" account with a ...) > NOT-FOR-US: Aztech port router > CVE-2008-6587 (Cross-site request forgery (CSRF) vulnerability in index.tmpl in Vuze ...) > - TODO: check > + - azureus <unfixed> > CVE-2008-6586 (Cross-site request forgery (CSRF) vulnerability in gui/index.php in ...) > NOT-FOR-US: ?Torrent (uTorrent) WebUI > CVE-2008-6585 (Cross-site request forgery (CSRF) vulnerability in html/admin.php in ...) > - TODO: check > + - torrentflux <unfixed> > CVE-2008-6584 (html/index.php in TorrentFlux 2.3 allows remote authenticated users to ...) > - TODO: check > + - torrentflux <unfixed> > CVE-2008-6583 (Buffer overflow in BS.player 2.27 build 959 allows remote attackers to ...) > NOT-FOR-US: BS.player > CVE-2009-1274 (Integer overflow in the qt_error parse_trak_atom function in ...) > @@ -1859,16 +1859,16 @@ > CVE-2009-0797 > RESERVED > CVE-2009-0796 (Cross-site scripting (XSS) vulnerability in Status.pm in ...) > - TODO: check > + - libapache2-mod-perl2 <unfixed> > CVE-2009-0795 [af_rose/x25 DoS] > REJECTED > - linux-2.6 <unfixed> > - linux-2.6.24 <unfixed> > CVE-2009-0794 (Integer overflow in the PulseAudioTargetDataL class in ...) > - TODO: check > + - openjdk-6 <unfixed> > CVE-2009-0793 (cmsxform.c in LittleCMS (aka lcms or liblcms) 1.18, as used in OpenJDK ...) > {DSA-1769-1} > - TODO: check > + - openjdk-6 <unfixed> > CVE-2009-0792 (Multiple integer overflows in icc.c in the International Color ...) > - argyll <unfixed> (low; bug #523427) > CVE-2009-0791 > @@ -2445,7 +2445,9 @@ > CVE-2009-0653 (OpenSSL, probably 0.9.6, does not verify the Basic Constraints for an ...) > - openssl 0.9.8-1 (bug #517791) > CVE-2009-0652 (Mozilla Firefox 3.0.6 does not properly prevent the literal rendering ...) > - TODO: check > + - iceape <unfixed> > + - xulrunner <unfixed> > + - iceweasel <unfixed> > CVE-2009-0651 (Unspecified vulnerability in the Veritas network daemon (aka vnetd) in ...) > NOT-FOR-US: Veritas network daemon > CVE-2009-0650 (Stack-based buffer overflow in the GetStatsFromLine function in TPTEST ...) > @@ -2924,7 +2926,7 @@ > - gs-gpl <removed> > - gs-esp <removed> > CVE-2009-0582 (The ntlm_challenge function in the NTLM SASL authentication mechanism ...) > - TODO: check > + - evolution-data-server <unfixed> > CVE-2009-0581 (Memory leak in LittleCMS (aka lcms or liblcms) before 1.18beta2, as ...) > {DSA-1769-1 DSA-1745-1} > - lcms 1.18.dfsg-1 (bug #522446) > @@ -3405,11 +3407,11 @@ > CVE-2008-6073 (StorageCrypt 2.0.1 does not properly encrypt disks, which allows local ...) > NOT-FOR-US: StorageCrypt > CVE-2008-6072 (Multiple unspecified vulnerabilities in GraphicsMagick before 1.1.14, ...) > - TODO: check > + - graphicsmagick <unfixed> > CVE-2008-6071 (Heap-based buffer overflow in the DecodeImage function in ...) > - TODO: check > + - graphicsmagick <unfixed> > CVE-2008-6070 (Multiple heap-based buffer underflows in the ReadPALMImage function in ...) > - TODO: check > + - graphicsmagick <unfixed> > CVE-2008-6069 (SQL injection vulnerability in e107chat.php in the eChat plugin 4.2 ...) > NOT-FOR-US: eChat plugin > CVE-2008-6068 (SQL injection vulnerability in the JoomlaDate (com_joomladate) ...) > @@ -3996,7 +3998,8 @@ > - dia 0.96.1-7.1 (low; bug #504251) > [etch] - dia <no-dsa> (Minor issue, only vulnerable when called from certain dir) > CVE-2008-5983 (Untrusted search path vulnerability in the PySys_SetArgv API function ...) > - TODO: check > + - python2.5 <unfixed> > + - python2.4 <unfixed> > CVE-2008-5982 (Format string vulnerability in BMC PATROL Agent before 3.7.30 allows ...) > NOT-FOR-US: BMC PATROL Agent > CVE-2009-0323 (Multiple stack-based buffer overflows in W3C Amaya Web Browser 10.0 ...) > @@ -4313,7 +4316,7 @@ > CVE-2009-0197 (Integer overflow in the FORMATS Plugin before 4.23 for IrfanView ...) > NOT-FOR-US: IrfanView > CVE-2009-0196 > - RESERVED > + - ghostscript <unfixed> > CVE-2009-0195 > RESERVED > CVE-2009-0194 > @@ -4414,7 +4417,7 @@ > CVE-2009-0160 > RESERVED > CVE-2009-0159 (Stack-based buffer overflow in the cookedprint function in ntpq/ntpq.c ...) > - TODO: check > + - ntp <unfixed> > CVE-2009-0158 > RESERVED > CVE-2009-0157 > @@ -5409,7 +5412,7 @@ > - linux-2.6 2.6.29-1 > - linux-2.6.24 <unfixed> > CVE-2009-0027 (The request handler in JBossWS in JBoss Enterprise Application ...) > - TODO: check > + - jbossas4 <unfixed> > CVE-2009-0026 (Multiple cross-site scripting (XSS) vulnerabilities in Apache ...) > NOT-FOR-US: Apache Jackrabbit > CVE-2009-0025 (BIND 9.6.0, 9.5.1, 9.5.0, 9.4.3, and earlier does not properly check ...) > @@ -5602,7 +5605,7 @@ > CVE-2008-5526 (DrWeb Anti-virus 4.44.0.09170, when Internet Explorer 6 or 7 is used, ...) > NOT-FOR-US: DrWeb Anti-virus > CVE-2008-5525 (ClamAV 0.94.1 and possibly 0.93.1, when Internet Explorer 6 or 7 is ...) > - TODO: check > + - clamav <unfixed> > NOTE: CVE claims it only happens when Internet Explorer 6 or 7 is used, but ClamAV doesn''t have any special code for IE > CVE-2008-5524 (CAT-QuickHeal 10.00 and possibly 9.50, when Internet Explorer 6 or 7 ...) > NOT-FOR-US: CAT-QuickHeal > @@ -5615,7 +5618,7 @@ > CVE-2008-5520 (AhnLab V3 2008.12.4.1 and possibly 2008.9.13.0, when Internet Explorer ...) > NOT-FOR-US: AhnLab V3 > CVE-2008-5519 (The JK Connector (aka mod_jk) 1.2.0 through 1.2.26 in Apache Tomcat ...) > - TODO: check > + - tomcat5.5 <unfixed> > CVE-2008-5518 > RESERVED > CVE-2008-5517 (The web interface in git (gitweb) 1.5.x before 1.5.6 allows remote ...) > @@ -7641,7 +7644,9 @@ > NOTE: not reproducible using iceweasel 3.0.1 > CVE-2008-4723 (Multiple cross-site scripting (XSS) vulnerabilities in Mozilla Firefox ...) > {CVE-2008-4724} > - TODO: check > + - iceape <unfixed> > + - xulrunner <unfixed> > + - iceweasel <unfixed> > NOTE: http://www.jorgan.users.cg.yu/ seems to be the original source > NOTE: Not enough details to tell if this is a real vulnerability. > NOTE: My guess is that file names containing <>& are incorrectly > @@ -13994,7 +13999,9 @@ > CVE-2008-2087 (SQL injection vulnerability in search_result.php in Softbiz Web Host ...) > NOT-FOR-US: Softbiz Web Host Directory Script > CVE-2008-2086 (Sun Java Web Start and Java Plug-in for JDK and JRE 6 Update 10 and ...) > - TODO: check > + - openjdk-6 <unfixed> > + - sun-java5 <unfixed> > + - sun-java6 <unfixed> > CVE-2008-2084 (SQL injection vulnerability in topics.php in the MyArticles 0.6 beta-1 ...) > NOT-FOR-US: MyArticles > CVE-2008-2083 (SQL injection vulnerability in directory.php in Prozilla Hosting ...) > @@ -14121,7 +14128,7 @@ > CVE-2008-2026 (Cross-site scripting (XSS) vulnerability in WebID/IISWebAgentIF.dll in ...) > NOT-FOR-US: RSA Authentication Agent > CVE-2008-2025 (Cross-site scripting (XSS) vulnerability in Apache Struts before ...) > - TODO: check > + - libstruts1.2-java <unfixed> > CVE-2008-2024 (Cross-site scripting (XSS) vulnerability in index.php in miniBB 2.2, ...) > NOT-FOR-US: miniBB > CVE-2008-2023 (Multiple SQL injection vulnerabilities in PD9 Software MegaBBS 2.2 ...) > @@ -29267,7 +29274,7 @@ > CVE-2007-2842 > RESERVED > CVE-2007-2841 [lighttpd DoS] > - RESERVED > + - lighttpd 1.4.16-1 (bug #428368) > NOTE: Duplicate of CVE-2007-3947, was assigned from Debian CNA and clashed with MITRE > NOTE: assignment > CVE-2007-2840 > @@ -42623,7 +42630,7 @@ > {DSA-1177-1} > - usermin <removed> (bug #374609) > CVE-2006-4245 > - RESERVED > + - archivemail <unfixed> > CVE-2006-4244 (SQL-Ledger 2.4.4 through 2.6.17 authenticates users by verifying that ...) > {DSA-1239-1} > - sql-ledger 2.6.18-1 (medium; bug #386519) > @@ -45262,7 +45269,6 @@ > {DSA-1112} > - mysql-dfsg-5.0 5.0.19-1 (bug #373913; high) > CVE-2006-3100 [termnetd buffer overflow] > - RESERVED > - termpkg 3.3-7 (bug #358028; medium) > CVE-2006-3085 (xt_sctp in netfilter for Linux kernel before 2.6.17.1 allows attackers ...) > - linux-2.6 2.6.16-15 > > > _______________________________________________ > Secure-testing-commits mailing list > Secure-testing-commits at lists.alioth.debian.org > http://lists.alioth.debian.org/mailman/listinfo/secure-testing-commits
Hi Michael, On Thu, Apr 16, 2009 at 11:10:38PM -0400, Michael S. Gilbert wrote:> would it make sense to integrate ubuntu''s security tracker with > debian''s, especially since the two distros are so closely related? > for example, [intrepid]/[jaunty] tags could be used to track > ubuntu-specific issues within the debian tracker. > > this would greatly reduce duplication of effort and make it clear to > the other team when the one pushes a fix since everyone will be getting > updates from the same tracker. it would also make a lot of sense for > the two teams to work more closely together. > > also, debsecan could finally be modified so that its output makes > sense on ubuntu (a pet peeve of mine). > > just a thought.It was discussed a lot when we were first building out our tracker, but our data sets are 4 times larger (we''ve effectively got 3 oldstables, 1 stable, and 1 testing). Also, we wanted to have a lot more information represented in our tracker that didn''t really fit the format of the secure-testing tracker. We modelled our tracker after the kernel-security tracker instead. Our results are here[1]. Our tracker''s support tools now both fetch hints from the Debian tracker as well as push hints from our back out. NFU''s have been working for a while now, but today I finally finished the first pass at noticing "TODO: check" entries where Ubuntu knows about a possible package match in the Debian archive. So, I''m trying to work as closely as possible, but we''ve got a lot of demands for statistics, bug links, credit, and our Canonical-supported/community-support split. There''s a ton of metadata we''re hauling around in our entries, and it seemed like it wouldn''t be much fun to jam all that into the Debian tracker. -Kees [1] https://code.launchpad.net/~ubuntu-security/ubuntu-cve-tracker/master -- Kees Cook @debian.org
Hi, * Kees Cook <kees at alioth.debian.org> [2009-04-17 09:59]:> Author: kees > Date: 2009-04-17 01:25:52 +0000 (Fri, 17 Apr 2009) > New Revision: 11636 > > Modified: > data/CVE/list > Log: > Sync from Ubuntu CVE tracker... > unfixed: archivemail azureus clamav evolution-data-server ghostscript graphicsmagick iceape iceweasel jbossas4 libapache2-mod-perl2 libstruts1.2-java linux-2.6 ntp openjdk-6 python2.4 python2.5 sun-java5 sun-java6 tomcat5.5 torrentflux typo3-src wireshark xulrunner > fixed: lighttpd tunapieCould you please switch that off again? Without prior discussion I think such bots are not acceptable. I also don''t think that we want automatic fixed entries, this is way to error prone. Also from what I experienced so far just adding <unfixed> entries doesn''t help that much, usually it takes very long until someone picks that up and files a bug. I want at least a further discussion of this until you switch this on again. It''s not that we were too lazy or to unskilled so far to play with soap and mark fixed bugs automatically in the tracker but as far as I can tell this wasn''t done on purpose. Cheers Nico -- Nico Golde - http://www.ngolde.de - nion at jabber.ccc.de - GPG: 0x73647CFF For security reasons, all text in this mail is double-rot13 encrypted. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://lists.alioth.debian.org/pipermail/secure-testing-commits/attachments/20090417/2d252cf7/attachment.pgp>
On Thu, 16 Apr 2009 23:40:00 -0700, Kees Cook wrote:> Hi Michael, > > On Thu, Apr 16, 2009 at 11:10:38PM -0400, Michael S. Gilbert wrote: > > would it make sense to integrate ubuntu''s security tracker with > > debian''s, especially since the two distros are so closely related? > > for example, [intrepid]/[jaunty] tags could be used to track > > ubuntu-specific issues within the debian tracker. > > > > this would greatly reduce duplication of effort and make it clear to > > the other team when the one pushes a fix since everyone will be getting > > updates from the same tracker. it would also make a lot of sense for > > the two teams to work more closely together. > > > > also, debsecan could finally be modified so that its output makes > > sense on ubuntu (a pet peeve of mine). > > > > just a thought. > > It was discussed a lot when we were first building out our tracker, but our > data sets are 4 times larger (we''ve effectively got 3 oldstables, 1 stable, > and 1 testing). Also, we wanted to have a lot more information represented > in our tracker that didn''t really fit the format of the secure-testing > tracker. We modelled our tracker after the kernel-security tracker > instead. Our results are here[1]. > > Our tracker''s support tools now both fetch hints from the Debian tracker as > well as push hints from our back out. NFU''s have been working for a while > now, but today I finally finished the first pass at noticing "TODO: check" > entries where Ubuntu knows about a possible package match in the Debian > archive. > > So, I''m trying to work as closely as possible, but we''ve got a lot of > demands for statistics, bug links, credit, and our > Canonical-supported/community-support split. There''s a ton of metadata > we''re hauling around in our entries, and it seemed like it wouldn''t be much > fun to jam all that into the Debian tracker.this seems very well-reasoned. i have one request to improve the process: please submit a ''NOTE'' with a link to the ubuntu patch whenever you issue a fix that hasn''t been issued by debian yet. this will help to increase the debian security team''s awareness of the work that has already been done, and hopefully make it easier/faster to issue fixes. in fact, it would be preferable to get this information during the process of preparing the patch, rather than after the USN is issued. also, would it be possible to coordinate security notices better? it looks bad when one of the distros releases a fix and the other doesn''t get the same fix out for days or weeks (i''m not saying to delay the fix, but to work more closely so both distros are ready to release at the same time). btw, it''s great that you''re now pushing your nfu''s to debian. at least that work will now get split between the two distros, rather than duplicating the effort. thanks! mike
On Fri, 17 Apr 2009 11:30:19 +0200, Nico Golde wrote:> Hi, > * Kees Cook <kees at alioth.debian.org> [2009-04-17 09:59]: > > Author: kees > > Date: 2009-04-17 01:25:52 +0000 (Fri, 17 Apr 2009) > > New Revision: 11636 > > > > Modified: > > data/CVE/list > > Log: > > Sync from Ubuntu CVE tracker... > > unfixed: archivemail azureus clamav evolution-data-server ghostscript graphicsmagick iceape iceweasel jbossas4 libapache2-mod-perl2 libstruts1.2-java linux-2.6 ntp openjdk-6 python2.4 python2.5 sun-java5 sun-java6 tomcat5.5 torrentflux typo3-src wireshark xulrunner > > fixed: lighttpd tunapie > > Could you please switch that off again? Without prior > discussion I think such bots are not acceptable. I also > don''t think that we want automatic fixed entries, this is > way to error prone. Also from what I experienced so far just > adding <unfixed> entries doesn''t help that much, usually it > takes very long until someone picks that up and files a bug. > > I want at least a further discussion of this until you > switch this on again. It''s not that we were too lazy or to > unskilled so far to play with soap and mark fixed bugs > automatically in the tracker but as far as I can tell this > wasn''t done on purpose.if they submitted (semi-automated) bug reports for all of the unfixed issues that they sync up, would that be sufficient to address your concerns? i agree that auto-marking fixed issues is quite dangerous and should not be done. mike
On Fri, Apr 17, 2009 at 09:48:47AM -0400, Michael S. Gilbert wrote:> i have one request to improve the process: please submit a ''NOTE'' with > a link to the ubuntu patch whenever you issue a fix that hasn''t been > issued by debian yet. this will help to increase the debian security > team''s awareness of the work that has already been done, and hopefully > make it easier/faster to issue fixes. in fact, it would be preferable > to get this information during the process of preparing the patch, > rather than after the USN is issued.I think this would be do-able. We don''t really have the best integration for our -security pocket when it comes to patch extraction. Right now the Ubuntu build-thing ("Soyuz") generates debdiff per-upload, but it gets easily confused by the -security pocket (i.e. it generate a diff against release, not -security origin). I have bugs open for them to get it fixed, so this will improve. Assuming I can generate a URL with a patch (and we''d have up to 5 patch URLs, depending on which of our releases were affected), the logic would be: if <unfixed> and patch URL exists, add NOTE:. Sounds right?> also, would it be possible to coordinate security notices better? it > looks bad when one of the distros releases a fix and the other doesn''t > get the same fix out for days or weeks (i''m not saying to delay the > fix, but to work more closely so both distros are ready to release at > the same time).For embargoed issues, this is supposed to happen already, by way of vendor-sec. Who all from Debian is on that list, and what are the policies and procedures you have in place for contacting maintainers? The recent udev thing seemed like a failure within Debian to contact the udev maintainer. One idea we''d had was to send email to the Debian maintainer for stuff we''ve ranked as "High" or "Critical", with something like "there''s an embargoed issue with $pkg, please make sure you get details from the Debian security team." For public issues, it''s a pretty different arrangement. The bulk of the packages in the archive are "community-supported" from Ubuntu''s perspective, so we do updates when there are volunteers to do debdiffs and more importantly, testing. That means we''re frequently behind Debian for those updates, and I don''t see a good way to stay up to date without people willing to test 4 stable releases of Ubuntu. For updates we _do_ publish, there is such a giant backlog of stuff to fix, we''re just trying to get stuff out the door as fast as possible. There tends to be very little time between our taking an issue, testing, and publishing a fix. I''m open to ideas; this has traditionally been a tricky area to get right.> btw, it''s great that you''re now pushing your nfu''s to debian. at least > that work will now get split between the two distros, rather than > duplicating the effort. thanks!Absolutely! I''ve been doing it for quite a while now, actually. I really do want to reduce work for both teams, and this was the lowest hanging fruit. Next lowest was putting in <unfixed> entries where Debian still had "TODO: check". Not really clear on what''s next, though. :) -Kees -- Kees Cook @debian.org
Hi, On Fri, Apr 17, 2009 at 10:57:38AM -0400, Michael S. Gilbert wrote:> On Fri, 17 Apr 2009 11:30:19 +0200, Nico Golde wrote: > > * Kees Cook <kees at alioth.debian.org> [2009-04-17 09:59]: > > > Author: kees > > > Date: 2009-04-17 01:25:52 +0000 (Fri, 17 Apr 2009) > > > New Revision: 11636 > > > > > > Modified: > > > data/CVE/list > > > Log: > > > Sync from Ubuntu CVE tracker... > > > unfixed: archivemail azureus clamav evolution-data-server ghostscript graphicsmagick iceape iceweasel jbossas4 libapache2-mod-perl2 libstruts1.2-java linux-2.6 ntp openjdk-6 python2.4 python2.5 sun-java5 sun-java6 tomcat5.5 torrentflux typo3-src wireshark xulrunner > > > fixed: lighttpd tunapie > > > > Could you please switch that off again? Without prior > > discussion I think such bots are not acceptable. I also > > don''t think that we want automatic fixed entries, this is > > way to error prone. Also from what I experienced so far just > > adding <unfixed> entries doesn''t help that much, usually it > > takes very long until someone picks that up and files a bug. > > > > I want at least a further discussion of this until you > > switch this on again. It''s not that we were too lazy or to > > unskilled so far to play with soap and mark fixed bugs > > automatically in the tracker but as far as I can tell this > > wasn''t done on purpose. > > if they submitted (semi-automated) bug reports for all of the unfixed > issues that they sync up, would that be sufficient to address your > concerns? > > i agree that auto-marking fixed issues is quite dangerous and should > not be done.Sorry for not being clear on this; the commit isn''t automatic. The tool on our side just adds <unfixed> entries, and then we go through and clean up stuff that has been obviously fixed (i.e. entries that have a DSA attached to it, etc). Since we''re highly time-limited, we can''t always go hunting through Debian changelogs or the BTS to see if a specific CVE is actually fixed. I had made the assumption that marking a "TODO: check" CVE with a package and "<unfixed>" was more information than leaving it "TODO: check". If this is not the case, I''m happy to just disable that part again. I was just trying to find a way to sync information from our tracker into Debian''s where Debian had no information listed. We could file bugs, but then, I imagine people would be upset about duplicates. I figured that a CVE that says "TODO: check" says absolutely nothing, and requires a triager to do a full analysis, where-as a CVE that has a package listed, marked "unfixed" means a triager would have to only examine that single package. As always, I''m open to any suggestions. I can take the package-adder out very easily and just go back to the old NFU-only merger. -Kees -- Kees Cook Ubuntu Security Team
Hi, * Kees Cook <kees at ubuntu.com> [2009-04-17 18:38]:> On Fri, Apr 17, 2009 at 10:57:38AM -0400, Michael S. Gilbert wrote: > > On Fri, 17 Apr 2009 11:30:19 +0200, Nico Golde wrote: > > > * Kees Cook <kees at alioth.debian.org> [2009-04-17 09:59]: > > > > Author: kees > > > > Date: 2009-04-17 01:25:52 +0000 (Fri, 17 Apr 2009) > > > > New Revision: 11636 > > > > > > > > Modified: > > > > data/CVE/list > > > > Log: > > > > Sync from Ubuntu CVE tracker... > > > > unfixed: archivemail azureus clamav evolution-data-server ghostscript graphicsmagick iceape iceweasel jbossas4 libapache2-mod-perl2 libstruts1.2-java linux-2.6 ntp openjdk-6 python2.4 python2.5 sun-java5 sun-java6 tomcat5.5 torrentflux typo3-src wireshark xulrunner > > > > fixed: lighttpd tunapie > > > > > > Could you please switch that off again? Without prior > > > discussion I think such bots are not acceptable. I also > > > don''t think that we want automatic fixed entries, this is > > > way to error prone. Also from what I experienced so far just > > > adding <unfixed> entries doesn''t help that much, usually it > > > takes very long until someone picks that up and files a bug. > > > > > > I want at least a further discussion of this until you > > > switch this on again. It''s not that we were too lazy or to > > > unskilled so far to play with soap and mark fixed bugs > > > automatically in the tracker but as far as I can tell this > > > wasn''t done on purpose. > > > > if they submitted (semi-automated) bug reports for all of the unfixed > > issues that they sync up, would that be sufficient to address your > > concerns?No. I see no difference between TODO: check and <unfixed> other than the knowledge of the package being in Debian. Adding <unfixed> is not adding any valuable research which you should do if you state it''s unfixed.> > i agree that auto-marking fixed issues is quite dangerous and should > > not be done. > > Sorry for not being clear on this; the commit isn''t automatic. The tool on > our side just adds <unfixed> entries, and then we go through and clean up > stuff that has been obviously fixed (i.e. entries that have a DSA attached > to it, etc).Ok> Since we''re highly time-limited, we can''t always go hunting through > Debian changelogs or the BTS to see if a specific CVE is actually fixed.This would be as well not sufficient, reading and checking the code is. Sure there will always be vulnerabilities where this can''t be done just because the fix is too complex, the code completely changed or for some other reason, but just following references and adding them.... this would make our work useless, this can be fully-automated but is of no real use.> I had made the assumption that marking a "TODO: check" CVE > with a package and > "<unfixed>" was more information than leaving it "TODO: check". If this is > not the case, I''m happy to just disable that part again. I was just trying > to find a way to sync information from our tracker into Debian''s where > Debian had no information listed.I really appreciate your work, especially because of the often mentioned flame that Ubuntu is not contributing back. Yes, <unfixed> is more information than a TODO: check but imho alone not of much use and I tend to prevent it unless I really don''t have the time and I know that other people will pick it up anyway (e.g. kernel issues). However as mentioned above my problem with <unfixed> is that most of these issues won''t get picked up by somebody. One reason for this is check-new-issues, it does check issues with TODO but not with <unfixed>. This maybe worth a discussion but in my personal opinion <unfixed> doesn''t add much value without a corresponding bug report and research.> We could file bugs, but then, I imagine people would be upset about > duplicates. I figured that a CVE that says "TODO: check" says absolutely > nothing, and requires a triager to do a full analysis, where-as a CVE that > has a package listed, marked "unfixed" means a triager would have to only > examine that single package.But unless it''s firefox there shouldn''t be a difference :) I think these are really corner-cases and in the vast majority we need commits that reflect good research.> As always, I''m open to any suggestions. I can take the package-adder out > very easily and just go back to the old NFU-only merger.I don''t want to represent the official meaning of the security team, it would be nice to get other peoples opinion too on this, but I think we should further discuss this. Cheers Nico -- Nico Golde - http://www.ngolde.de - nion at jabber.ccc.de - GPG: 0x73647CFF For security reasons, all text in this mail is double-rot13 encrypted. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://lists.alioth.debian.org/pipermail/secure-testing-commits/attachments/20090418/a10d0111/attachment.pgp>
On Sat, 18 Apr 2009 17:01:36 +0200Nico Golde wrote:> * Kees Cook [2009-04-17 18:38]: > > On Fri, Apr 17, 2009 at 10:57:38AM -0400, Michael S. Gilbert wrote: > > > On Fri, 17 Apr 2009 11:30:19 +0200, Nico Golde wrote: > > > > * Kees Cook [2009-04-17 09:59]: > > > > > Author: kees > > > > > Date: 2009-04-17 01:25:52 +0000 (Fri, 17 Apr 2009) > > > > > New Revision: 11636 > > > > > > > > > > Modified: > > > > > data/CVE/list > > > > > Log: > > > > > Sync from Ubuntu CVE tracker... > > > > > unfixed: archivemail azureus clamav evolution-data-server ghostscript graphicsmagick iceape iceweasel jbossas4 libapache2-mod-perl2 libstruts1.2-java linux-2.6 ntp openjdk-6 python2.4 python2.5 sun-java5 sun-java6 tomcat5.5 torrentflux typo3-src wireshark xulrunner > > > > > fixed: lighttpd tunapie > > > > > > > > Could you please switch that off again? Without prior > > > > discussion I think such bots are not acceptable. I also > > > > don''t think that we want automatic fixed entries, this is > > > > way to error prone. Also from what I experienced so far just > > > > adding <unfixed> entries doesn''t help that much, usually it > > > > takes very long until someone picks that up and files a bug. > > > > > > > > I want at least a further discussion of this until you > > > > switch this on again. It''s not that we were too lazy or to > > > > unskilled so far to play with soap and mark fixed bugs > > > > automatically in the tracker but as far as I can tell this > > > > wasn''t done on purpose. > > > > > > if they submitted (semi-automated) bug reports for all of the unfixed > > > issues that they sync up, would that be sufficient to address your > > > concerns? > > No. I see no difference between TODO: check and <unfixed> > other than the knowledge of the package being in Debian. > Adding <unfixed> is not adding any valuable research which > you should do if you state it''s unfixed. > > > > i agree that auto-marking fixed issues is quite dangerous and should > > > not be done. > > > > Sorry for not being clear on this; the commit isn''t automatic. The tool on > > our side just adds <unfixed> entries, and then we go through and clean up > > stuff that has been obviously fixed (i.e. entries that have a DSA attached > > to it, etc). > > Ok > > > Since we''re highly time-limited, we can''t always go hunting through > > Debian changelogs or the BTS to see if a specific CVE is actually fixed. > > This would be as well not sufficient, reading and checking > the code is. Sure there will always be vulnerabilities where > this can''t be done just because the fix is too complex, the > code completely changed or for some other reason, but just > following references and adding them.... this would make our > work useless, this can be fully-automated but is of no real > use. > > > I had made the assumption that marking a "TODO: check" CVE > > with a package and > > "<unfixed>" was more information than leaving it "TODO: check". If this is > > not the case, I''m happy to just disable that part again. I was just trying > > to find a way to sync information from our tracker into Debian''s where > > Debian had no information listed. > > I really appreciate your work, especially because of the > often mentioned flame that Ubuntu is not contributing back. > Yes, <unfixed> is more information than a TODO: check but > imho alone not of much use and I tend to prevent it unless I > really don''t have the time and I know that other people will > pick it up anyway (e.g. kernel issues). However as mentioned > above my problem with <unfixed> is that most of these issues > won''t get picked up by somebody. One reason for this is > check-new-issues, it does check issues with TODO but not > with <unfixed>. > > This maybe worth a discussion but in my personal opinion > <unfixed> doesn''t add much value without a corresponding bug > report and research. > > > We could file bugs, but then, I imagine people would be upset about > > duplicates. I figured that a CVE that says "TODO: check" says absolutely > > nothing, and requires a triager to do a full analysis, where-as a CVE that > > has a package listed, marked "unfixed" means a triager would have to only > > examine that single package. > > But unless it''s firefox there shouldn''t be a difference :) I > think these are really corner-cases and in the vast majority > we need commits that reflect good research. > > > As always, I''m open to any suggestions. I can take the package-adder out > > very easily and just go back to the old NFU-only merger. > > I don''t want to represent the official meaning of the > security team, it would be nice to get other peoples opinion > too on this, but I think we should further discuss this.i also don''t want to speak for the entire debian security team, but i think that what is really needed is bug reports (at least for your traiged unembargoed issues). this is the only way that the package maintainer gets made aware of security issues (changes to the security tracker are not automatically conveyed to maintainers), and the maintainers are primarily responsible for making the necessary fixes. hence, i think the following would be a good process for ubuntu security triagers: 1. triage issue in ubuntu 2. check status of CVE in debian (debsecan could be used for this) 3. submit bug report to launchpad (with link to debian bug report if it already exists) 4. update ubuntu security tracker 5. if no existing debian report, submit bug to bugs.debian.org (note that bin/report-vuln in secure-testing svn makes this semi-automated), and preferably include a link to the launchpad report so the debian maintainer can make use of your existing work 6. wait for email from the debian bts with bug # and update data/CVE/list with this info as for embargoed issues, i think that they are currently handled reasonably well (at least from what i see on the outside), and i wouldn''t suggest changing the process (except to make sure someone takes responsiblity on debian''s side when members are known to be on vacation). mike
On Fri, 17 Apr 2009 08:43:27 -0700 Kees Cook wrote:> On Fri, Apr 17, 2009 at 09:48:47AM -0400, Michael S. Gilbert wrote: > > i have one request to improve the process: please submit a ''NOTE'' with > > a link to the ubuntu patch whenever you issue a fix that hasn''t been > > issued by debian yet. this will help to increase the debian security > > team''s awareness of the work that has already been done, and hopefully > > make it easier/faster to issue fixes. in fact, it would be preferable > > to get this information during the process of preparing the patch, > > rather than after the USN is issued. > > I think this would be do-able. We don''t really have the best integration > for our -security pocket when it comes to patch extraction. Right now the > Ubuntu build-thing ("Soyuz") generates debdiff per-upload, but it gets > easily confused by the -security pocket (i.e. it generate a diff against > release, not -security origin). I have bugs open for them to get it fixed, > so this will improve. > > Assuming I can generate a URL with a patch (and we''d have up to 5 patch > URLs, depending on which of our releases were affected), the logic would > be: if <unfixed> and patch URL exists, add NOTE:. Sounds right?a better logic would be: if no DSA issued yet for the particular CVE add ''NOTE: ubuntu bug <launchpad bug url>\n NOTE: ubuntu patch <patch url>'' on second thought, i''m not sure if this information would be so useful in the tracker. it would be more useful to transmit directly to the debian maintainer via a new bug report or as additional information in an existing bug report. note that this could be fairly automated: you could retrieve the bug number from debian''s secure-testing svn, and send an automatic mail to that bug number.> > also, would it be possible to coordinate security notices better? it > > looks bad when one of the distros releases a fix and the other doesn''t > > get the same fix out for days or weeks (i''m not saying to delay the > > fix, but to work more closely so both distros are ready to release at > > the same time). > > For embargoed issues, this is supposed to happen already, by way of > vendor-sec. Who all from Debian is on that list, and what are the policies > and procedures you have in place for contacting maintainers? > > The recent udev thing seemed like a failure within Debian to contact > the udev maintainer. One idea we''d had was to send email to the Debian > maintainer for stuff we''ve ranked as "High" or "Critical", with something > like "there''s an embargoed issue with $pkg, please make sure you get > details from the Debian security team."i think embargoed issues are handled OK as is.> For public issues, it''s a pretty different arrangement. The bulk of the > packages in the archive are "community-supported" from Ubuntu''s > perspective, so we do updates when there are volunteers to do debdiffs and > more importantly, testing. That means we''re frequently behind Debian for > those updates, and I don''t see a good way to stay up to date without people > willing to test 4 stable releases of Ubuntu. For updates we _do_ publish, > there is such a giant backlog of stuff to fix, we''re just trying to get > stuff out the door as fast as possible. There tends to be very little time > between our taking an issue, testing, and publishing a fix. > > I''m open to ideas; this has traditionally been a tricky area to get right.i''m more concerned about the issues where ubuntu releases a fix before debian. during the process of preparing the fix, i would like to see better coordination with the debian package maintainer and security team so that they are right there with you and can get the DSA out pretty much at the same time that you get your USN out. thanks again for your hard work and interest on this! mike
Nico Golde wrote:> > > > I want at least a further discussion of this until you > > > > switch this on again. It''s not that we were too lazy or to > > > > unskilled so far to play with soap and mark fixed bugs > > > > automatically in the tracker but as far as I can tell this > > > > wasn''t done on purpose. > > > > > > if they submitted (semi-automated) bug reports for all of the unfixed > > > issues that they sync up, would that be sufficient to address your > > > concerns? > > No. I see no difference between TODO: check and <unfixed> > other than the knowledge of the package being in Debian. > Adding <unfixed> is not adding any valuable research which > you should do if you state it''s unfixed.But the knowledge that a package is in Debian, is still useful. But, maybe they should rather be added as TODO: TRIAGE - foobar <unfixed> since at least the following still need to be done manually: - file a bug report - triage - if needed open RT ticket At least the first part can also be done by people outside the Debian Security Team (such a the bugs filed by Michael yesterday).> > > > > unfixed: archivemail azureus clamav evolution-data-server ghostscript graphicsmagick iceape iceweasel jbossas4 libapache2-mod-perl2 libstruts1.2-java linux-2.6 ntp openjdk-6 python2.4 python2.5 sun-java5 sun-java6 tomcat5.5 torrentflux typo3-src wireshark xulrunner > > > > > fixed: lighttpd tunapieThe "fixed" entries added are very useful! (Of course, it should still be reviewed as all commits) Kees, how do you merge back information that has been changed in our tracker? Manually or automated as well? Cheers, Moritz
Hi, * Kees Cook <kees at alioth.debian.org> [2009-04-17 09:59]: [...]> CVE-2008-6594 (SQL injection vulnerability in the cm_rdfexport extension for TYPO3 ...) > - TODO: check > + - typo3-src <unfixed>Looks like we have our first false-positive from the "auto"-merge unless I missed something, can''t find any sources of this extension in typo3-src. Cheers Nico -- Nico Golde - http://www.ngolde.de - nion at jabber.ccc.de - GPG: 0x73647CFF For security reasons, all text in this mail is double-rot13 encrypted. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://lists.alioth.debian.org/pipermail/secure-testing-commits/attachments/20090422/b031af9b/attachment-0001.pgp>