http://mark.foster.cc/ | http://conshell.net/
From edwin at FreeBSD.org Fri Nov 14 07:00:21 2008
From: edwin at FreeBSD.org (edwin@FreeBSD.org)
Date: Fri Nov 14 09:25:38 2008
Subject: ports/128868: [vuxml] security/gnutls: CVE-2008-4989 and update
to 2.4.2
Message-ID: <200811141500.mAEF0LFM004825@freefall.freebsd.org>
Synopsis: [vuxml] security/gnutls: CVE-2008-4989 and update to 2.4.2
Responsible-Changed-From-To: freebsd-ports-bugs->novel
Responsible-Changed-By: edwin
Responsible-Changed-When: Fri Nov 14 15:00:20 UTC 2008
Responsible-Changed-Why:
Over to maintainer (via the GNATS Auto Assign Tool)
http://www.freebsd.org/cgi/query-pr.cgi?pr=128868
From rea-fbsd at codelabs.ru Fri Nov 14 13:20:49 2008
From: rea-fbsd at codelabs.ru (Eygene Ryabinkin)
Date: Fri Nov 14 13:20:58 2008
Subject: portaudit, vuxml & OVAL data
In-Reply-To: <491DA571.2060105@foster.cc>
References: <491DA571.2060105@foster.cc>
Message-ID:
Mark, good day.
Fri, Nov 14, 2008 at 08:21:05AM -0800, Mark Foster wrote:
> I have a project idea regarding the extension of portaudit (which now
> solely relies on the vuxml data from security/vuxml) to additionally
> parse OVAL (CVE) data from the SCAP project.
> http://nvd.nist.gov/scap.cfm
> http://oval.mitre.org/
>
> I see that they already have a schema definition for FreeBSD found here:
> http://oval.mitre.org/language/download/schema/version5.5/index.html
I had glanced over this: there are FreeBSD-specific test definitions,
but currently there are no FreeBSD-specific vulnerability data at OVAL.
At least I had not found one.
> I could see this turning into a oval2portaudit tool accompanied by a
> modification of portaudit (if necessary) to accomodate
> additional/disparate data sources.
I could be a bit stupid, but I don't understand how the data from CVE is
pushed to the OVAL. From what I had seen, there should be some person
who will do it: looking at the sources of OVAL data for the different
OSes, I had found that one should still write some tests to see if the
vulnerability is applicable to the current system state. If it is
really so, then writing such tests is more-or-less equal to the creation
of a new VuXML entry.
I have another idea: use CVE XML feeds,
http://nvd.nist.gov/download.cfm#CVE_FEED
to create drafts of the VuXML entries that will be passed to the
human for the inspection. Such inspection is needed anyway, because,
for example, FreeBSD could have the port with the backported patch.
So, feed contents will tell us that the program is vulnerable, but
the reality will be different.
--
Eygene
_ ___ _.--. #
\`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, / # while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / # -- FreeBSD Developers handbook
{_.-``-' {_/ #
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-security/attachments/20081114/1246f45c/attachment.pgp
From rea-fbsd at codelabs.ru Tue Nov 18 02:40:01 2008
From: rea-fbsd at codelabs.ru (Eygene Ryabinkin)
Date: Tue Nov 18 02:40:41 2008
Subject: ports/128956: [patch] [vuxml] multiple vulnerabilities in PHP 5.2.6
Message-ID: <20081118103433.38D5817115@shadow.codelabs.ru>
>Number: 128956
>Category: ports
>Synopsis: [patch] [vuxml] multiple vulnerabilities in PHP 5.2.6
>Confidential: no
>Severity: serious
>Priority: high
>Responsible: freebsd-ports-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Tue Nov 18 10:40:00 UTC 2008
>Closed-Date:
>Last-Modified:
>Originator: Eygene Ryabinkin
>Release: FreeBSD 7.1-PRERELEASE amd64
>Organization:
Code Labs
>Environment:
System: FreeBSD 7.1-PRERELEASE amd64
>Description:
There are some vulnerabilities in the stock PHP 5.2.6 that were silently
fixed in the CVS, but after 5.2.6 was out.
>How-To-Repeat:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2829
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3659
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3660
>Fix:
The following patches should fix all three issues. I had mildly
tested them in my setups.
--- 5.2.6_2-to-5.2.6_3-fix-cve-2008-3659.3660.diff begins here ---
diff -urN ./Makefile ../php5/Makefile
--- ./Makefile 2008-11-18 11:49:16.000000000 +0300
+++ ../php5/Makefile 2008-11-18 11:49:27.000000000 +0300
@@ -7,7 +7,7 @@
PORTNAME= php5
PORTVERSION= 5.2.6
-PORTREVISION?= 2
+PORTREVISION?= 3
CATEGORIES?= lang devel www
MASTER_SITES= ${MASTER_SITE_PHP}
MASTER_SITE_SUBDIR= distributions
diff -urN ./files/patch-CVE-2008-3659 ../php5/files/patch-CVE-2008-3659
--- ./files/patch-CVE-2008-3659 1970-01-01 03:00:00.000000000 +0300
+++ ../php5/files/patch-CVE-2008-3659 2008-11-18 11:49:55.000000000 +0300
@@ -0,0 +1,27 @@
+Patch for CVE-2008-3659.
+
+Obtained from: http://cvs.php.net/viewvc.cgi/ZendEngine2/zend_operators.h?r1=1.94.2.4.2.11&r2=1.94.2.4.2.12&view=patch
+See also: http://news.php.net/php.cvs/52002
+See also: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3659
+
+--- Zend/zend_operators.h 2007/12/31 07:20:03 1.94.2.4.2.11
++++ Zend/zend_operators.h 2008/08/05 20:11:17 1.94.2.4.2.12
+@@ -17,7 +17,7 @@
+ +----------------------------------------------------------------------+
+ */
+
+-/* $Id: zend_operators.h,v 1.94.2.4.2.11 2007/12/31 07:20:03 sebastian Exp $ */
++/* $Id: zend_operators.h,v 1.94.2.4.2.12 2008/08/05 20:11:17 stas Exp $ */
+
+ #ifndef ZEND_OPERATORS_H
+ #define ZEND_OPERATORS_H
+@@ -220,6 +220,9 @@
+ char *p = haystack;
+ char ne = needle[needle_len-1];
+
++ if(needle_len > end-haystack) {
++ return NULL;
++ }
+ end -= needle_len;
+
+ while (p <= end) {
diff -urN ./files/patch-CVE-2008-3660 ../php5/files/patch-CVE-2008-3660
--- ./files/patch-CVE-2008-3660 1970-01-01 03:00:00.000000000 +0300
+++ ../php5/files/patch-CVE-2008-3660 2008-11-18 12:15:23.000000000 +0300
@@ -0,0 +1,82 @@
+Patch for CVE-2008-3660
+
+Obtained from: http://cvs.php.net/viewvc.cgi/php-src/sapi/cgi/cgi_main.c?r1=1.267.2.15.2.57&r2=1.267.2.15.2.58&view=patch
+See also: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3660
+See also: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=499987
+Notes: removed 'Id' hunk and reapplied this patch for the php-5.2.6
+
+--- sapi/cgi/cgi_main.c.orig 2008-04-09 13:16:40.000000000 +0400
++++ sapi/cgi/cgi_main.c 2008-11-18 12:08:10.000000000 +0300
+@@ -765,6 +765,39 @@
+ }
+ /* }}} */
+
++/* {{{ is_valid_path
++ *
++ * some server configurations allow '..' to slip through in the
++ * translated path. We'll just refuse to handle such a path.
++ */
++static int is_valid_path(const char *path)
++{
++ const char *p;
++
++ if (!path) {
++ return 0;
++ }
++ p = strstr(path, "..");
++ if (p) {
++ if ((p == path || IS_SLASH(*(p-1))) &&
++ (*(p+2) == 0 || IS_SLASH(*(p+2)))) {
++ return 0;
++ }
++ while (1) {
++ p = strstr(p+1, "..");
++ if (!p) {
++ break;
++ }
++ if (IS_SLASH(*(p-1)) &&
++ (*(p+2) == 0 || IS_SLASH(*(p+2)))) {
++ return 0;
++ }
++ }
++ }
++ return 1;
++}
++/* }}} */
++
+ /* {{{ init_request_info
+
+ initializes request_info structure
+@@ -1061,9 +1094,7 @@
+ if (pt) {
+ efree(pt);
+ }
+- /* some server configurations allow '..' to slip through in the
+- translated path. We'll just refuse to handle such a path. */
+- if (script_path_translated && !strstr(script_path_translated, "..")) {
++ if (is_valid_path(script_path_translated)) {
+ SG(request_info).path_translated = estrdup(script_path_translated);
+ }
+ } else {
+@@ -1094,9 +1125,7 @@
+ } else {
+ SG(request_info).request_uri = env_script_name;
+ }
+- /* some server configurations allow '..' to slip through in the
+- translated path. We'll just refuse to handle such a path. */
+- if (script_path_translated && !strstr(script_path_translated, "..")) {
++ if (is_valid_path(script_path_translated)) {
+ SG(request_info).path_translated = estrdup(script_path_translated);
+ }
+ free(real_path);
+@@ -1114,9 +1143,7 @@
+ script_path_translated = env_path_translated;
+ }
+ #endif
+- /* some server configurations allow '..' to slip through in the
+- translated path. We'll just refuse to handle such a path. */
+- if (script_path_translated && !strstr(script_path_translated, "..")) {
++ if (is_valid_path(script_path_translated)) {
+ SG(request_info).path_translated = estrdup(script_path_translated);
+ }
+ #if ENABLE_PATHINFO_CHECK
--- 5.2.6_2-to-5.2.6_3-fix-cve-2008-3659.3660.diff ends here ---
--- imap-5.2.6_2-to-5.2.6_3-fix-cve-2008-2829.diff begins here ---
diff -urN ./files/patch-CVE-2008-2829 ../php5-imap/files/patch-CVE-2008-2829
--- ./files/patch-CVE-2008-2829 1970-01-01 03:00:00.000000000 +0300
+++ ../php5-imap/files/patch-CVE-2008-2829 2008-11-18 13:20:19.000000000 +0300
@@ -0,0 +1,282 @@
+Fix for CVE-2008-2829
+
+Obtained from: http://cvs.php.net/viewvc.cgi/php-src/ext/imap/php_imap.c?r1=1.259&r2=1.260&view=patch
+Notes: reapplied to php-5.6.2, skipped 'Id' hunk and modified hunk marked
+ '-3213,7 +3214,7'.
+
+--- php_imap.c.orig 2008-04-17 15:04:49.000000000 +0400
++++ php_imap.c 2008-11-18 13:03:02.000000000 +0300
+@@ -40,6 +40,7 @@
+ #include "ext/standard/php_string.h"
+ #include "ext/standard/info.h"
+ #include "ext/standard/file.h"
++#include "ext/standard/php_smart_str.h"
+
+ #ifdef ERROR
+ #undef ERROR
+@@ -66,10 +67,11 @@
+ #define SENDBUFLEN 16385
+ #endif
+
++
+ static void _php_make_header_object(zval *myzvalue, ENVELOPE *en TSRMLS_DC);
+ static void _php_imap_add_body(zval *arg, BODY *body TSRMLS_DC);
+-static void _php_imap_parse_address(ADDRESS *addresslist, char **fulladdress, zval *paddress TSRMLS_DC);
+-static int _php_imap_address_size(ADDRESS *addresslist);
++static char* _php_imap_parse_address(ADDRESS *addresslist, zval *paddress TSRMLS_DC);
++static char* _php_rfc822_write_address(ADDRESS *addresslist TSRMLS_DC);
+
+ /* the gets we use */
+ static char *php_mail_gets(readfn_t f, void *stream, unsigned long size, GETS_DATA *md);
+@@ -2109,7 +2111,7 @@
+ {
+ zval **mailbox, **host, **personal;
+ ADDRESS *addr;
+- char string[MAILTMPLEN];
++ char *string;
+
+ if (ZEND_NUM_ARGS() != 3 || zend_get_parameters_ex(3, &mailbox, &host, &personal) == FAILURE) {
+ ZEND_WRONG_PARAM_COUNT();
+@@ -2137,13 +2139,12 @@
+ addr->error=NIL;
+ addr->adl=NIL;
+
+- if (_php_imap_address_size(addr) >= MAILTMPLEN) {
++ string = _php_rfc822_write_address(addr TSRMLS_CC);
++ if (string) {
++ RETVAL_STRING(string, 0);
++ } else {
+ RETURN_FALSE;
+ }
+-
+- string[0]='\0';
+- rfc822_write_address(string, addr);
+- RETVAL_STRING(string, 1);
+ }
+ /* }}} */
+
+@@ -2873,7 +2874,7 @@
+ zval **streamind, **sequence, **pflags;
+ pils *imap_le_struct;
+ zval *myoverview;
+- char address[MAILTMPLEN];
++ char *address;
+ long status, flags=0L;
+ int myargc = ZEND_NUM_ARGS();
+
+@@ -2908,17 +2909,19 @@
+ if (env->subject) {
+ add_property_string(myoverview, "subject", env->subject, 1);
+ }
+- if (env->from && _php_imap_address_size(env->from) < MAILTMPLEN) {
++ if (env->from) {
+ env->from->next=NULL;
+- address[0] = '\0';
+- rfc822_write_address(address, env->from);
+- add_property_string(myoverview, "from", address, 1);
++ address =_php_rfc822_write_address(env->from TSRMLS_CC);
++ if (address) {
++ add_property_string(myoverview, "from", address, 0);
++ }
+ }
+- if (env->to && _php_imap_address_size(env->to) < MAILTMPLEN) {
++ if (env->to) {
+ env->to->next = NULL;
+- address[0] = '\0';
+- rfc822_write_address(address, env->to);
+- add_property_string(myoverview, "to", address, 1);
++ address = _php_rfc822_write_address(env->to TSRMLS_CC);
++ if (address) {
++ add_property_string(myoverview, "to", address, 0);
++ }
+ }
+ if (env->date) {
+ add_property_string(myoverview, "date", env->date, 1);
+@@ -3858,6 +3861,43 @@
+ /* }}} */
+
+ /* Support Functions */
++
++#ifdef HAVE_RFC822_OUTPUT_ADDRESS_LIST
++/* {{{ _php_rfc822_soutr
++ */
++static long _php_rfc822_soutr (void *stream, char *string)
++{
++ smart_str *ret = (smart_str*)stream;
++ int len = strlen(string);
++
++ smart_str_appendl(ret, string, len);
++ return LONGT;
++}
++
++/* }}} */
++
++/* {{{ _php_rfc822_write_address
++ */
++static char* _php_rfc822_write_address(ADDRESS *addresslist TSRMLS_DC)
++{
++ char address[MAILTMPLEN];
++ smart_str ret = {0};
++ RFC822BUFFER buf;
++
++ buf.beg = address;
++ buf.cur = buf.beg;
++ buf.end = buf.beg + sizeof(address) - 1;
++ buf.s = &ret;
++ buf.f = _php_rfc822_soutr;
++ rfc822_output_address_list(&buf, addresslist, 0, NULL);
++ rfc822_output_flush(&buf);
++ smart_str_0(&ret);
++ return ret.c;
++}
++/* }}} */
++
++#else
++
+ /* {{{ _php_imap_get_address_size
+ */
+ static int _php_imap_address_size (ADDRESS *addresslist)
+@@ -3887,26 +3927,33 @@
+
+ /* }}} */
+
++/* {{{ _php_rfc822_write_address
++ */
++static char* _php_rfc822_write_address(ADDRESS *addresslist TSRMLS_DC)
++{
++ char address[SENDBUFLEN];
+
++ if (_php_imap_address_size(addresslist) >= SENDBUFLEN) {
++ php_error_docref(NULL TSRMLS_CC, E_ERROR, "Address buffer overflow");
++ return NULL;
++ }
++ address[0] = 0;
++ rfc822_write_address(address, addresslist);
++ return estrdup(address);
++}
++/* }}} */
++#endif
+ /* {{{ _php_imap_parse_address
+ */
+-static void _php_imap_parse_address (ADDRESS *addresslist, char **fulladdress, zval *paddress TSRMLS_DC)
++static char* _php_imap_parse_address (ADDRESS *addresslist, zval *paddress TSRMLS_DC)
+ {
++ char *fulladdress;
+ ADDRESS *addresstmp;
+ zval *tmpvals;
+- char *tmpstr;
+- int len=0;
+
+ addresstmp = addresslist;
+
+- if ((len = _php_imap_address_size(addresstmp))) {
+- tmpstr = (char *) pemalloc(len + 1, 1);
+- tmpstr[0] = '\0';
+- rfc822_write_address(tmpstr, addresstmp);
+- *fulladdress = tmpstr;
+- } else {
+- *fulladdress = NULL;
+- }
++ fulladdress = _php_rfc822_write_address(addresstmp TSRMLS_CC);
+
+ addresstmp = addresslist;
+ do {
+@@ -3918,6 +3965,7 @@
+ if (addresstmp->host) add_property_string(tmpvals, "host", addresstmp->host, 1);
+ add_next_index_object(paddress, tmpvals TSRMLS_CC);
+ } while ((addresstmp = addresstmp->next));
++ return fulladdress;
+ }
+ /* }}} */
+
+@@ -3944,10 +3992,9 @@
+ if (en->to) {
+ MAKE_STD_ZVAL(paddress);
+ array_init(paddress);
+- _php_imap_parse_address(en->to, &fulladdress, paddress TSRMLS_CC);
++ fulladdress = _php_imap_parse_address(en->to, paddress TSRMLS_CC);
+ if (fulladdress) {
+- add_property_string(myzvalue, "toaddress", fulladdress, 1);
+- free(fulladdress);
++ add_property_string(myzvalue, "toaddress", fulladdress, 0);
+ }
+ add_assoc_object(myzvalue, "to", paddress TSRMLS_CC);
+ }
+@@ -3955,10 +4002,9 @@
+ if (en->from) {
+ MAKE_STD_ZVAL(paddress);
+ array_init(paddress);
+- _php_imap_parse_address(en->from, &fulladdress, paddress TSRMLS_CC);
++ fulladdress = _php_imap_parse_address(en->from, paddress TSRMLS_CC);
+ if (fulladdress) {
+- add_property_string(myzvalue, "fromaddress", fulladdress, 1);
+- free(fulladdress);
++ add_property_string(myzvalue, "fromaddress", fulladdress, 0);
+ }
+ add_assoc_object(myzvalue, "from", paddress TSRMLS_CC);
+ }
+@@ -3966,10 +4012,9 @@
+ if (en->cc) {
+ MAKE_STD_ZVAL(paddress);
+ array_init(paddress);
+- _php_imap_parse_address(en->cc, &fulladdress, paddress TSRMLS_CC);
++ fulladdress = _php_imap_parse_address(en->cc, paddress TSRMLS_CC);
+ if (fulladdress) {
+- add_property_string(myzvalue, "ccaddress", fulladdress, 1);
+- free(fulladdress);
++ add_property_string(myzvalue, "ccaddress", fulladdress, 0);
+ }
+ add_assoc_object(myzvalue, "cc", paddress TSRMLS_CC);
+ }
+@@ -3977,10 +4022,9 @@
+ if (en->bcc) {
+ MAKE_STD_ZVAL(paddress);
+ array_init(paddress);
+- _php_imap_parse_address(en->bcc, &fulladdress, paddress TSRMLS_CC);
++ fulladdress = _php_imap_parse_address(en->bcc, paddress TSRMLS_CC);
+ if (fulladdress) {
+- add_property_string(myzvalue, "bccaddress", fulladdress, 1);
+- free(fulladdress);
++ add_property_string(myzvalue, "bccaddress", fulladdress, 0);
+ }
+ add_assoc_object(myzvalue, "bcc", paddress TSRMLS_CC);
+ }
+@@ -3988,10 +4032,9 @@
+ if (en->reply_to) {
+ MAKE_STD_ZVAL(paddress);
+ array_init(paddress);
+- _php_imap_parse_address(en->reply_to, &fulladdress, paddress TSRMLS_CC);
++ fulladdress = _php_imap_parse_address(en->reply_to, paddress TSRMLS_CC);
+ if (fulladdress) {
+- add_property_string(myzvalue, "reply_toaddress", fulladdress, 1);
+- free(fulladdress);
++ add_property_string(myzvalue, "reply_toaddress", fulladdress, 0);
+ }
+ add_assoc_object(myzvalue, "reply_to", paddress TSRMLS_CC);
+ }
+@@ -3999,10 +4042,9 @@
+ if (en->sender) {
+ MAKE_STD_ZVAL(paddress);
+ array_init(paddress);
+- _php_imap_parse_address(en->sender, &fulladdress, paddress TSRMLS_CC);
++ fulladdress = _php_imap_parse_address(en->sender, paddress TSRMLS_CC);
+ if (fulladdress) {
+- add_property_string(myzvalue, "senderaddress", fulladdress, 1);
+- free(fulladdress);
++ add_property_string(myzvalue, "senderaddress", fulladdress, 0);
+ }
+ add_assoc_object(myzvalue, "sender", paddress TSRMLS_CC);
+ }
+@@ -4010,10 +4052,9 @@
+ if (en->return_path) {
+ MAKE_STD_ZVAL(paddress);
+ array_init(paddress);
+- _php_imap_parse_address(en->return_path, &fulladdress, paddress TSRMLS_CC);
++ fulladdress = _php_imap_parse_address(en->return_path, paddress TSRMLS_CC);
+ if (fulladdress) {
+- add_property_string(myzvalue, "return_pathaddress", fulladdress, 1);
+- free(fulladdress);
++ add_property_string(myzvalue, "return_pathaddress", fulladdress, 0);
+ }
+ add_assoc_object(myzvalue, "return_path", paddress TSRMLS_CC);
+ }
--- imap-5.2.6_2-to-5.2.6_3-fix-cve-2008-2829.diff ends here ---
I assume that they all will go in one shot, so the following VuXML
entries use 5.2.6_3 as the first version where issues were fixed.
--- cve-2008-2829.xml begins here ---
PHP 5.x -- Denial of Service and possible arbitrary code execution in the IMAP extension
php5-imap
5.2.6_3
Entry for CVE-2008-2829 says:
php_imap.c in PHP 5.2.5, 5.2.6, 4.x, and other versions, uses
obsolete API calls that allow context-dependent attackers to
cause a denial of service (crash) and possibly execute arbitrary
code via a long IMAP request, which triggers an "rfc822.c legacy
routine buffer overflow" error message.
CVE-2008-2829
http://bugs.php.net/bug.php?id=42862
http://bugs.php.net/bug.php?id=40925
http://cvs.php.net/viewvc.cgi/php-src/ext/imap/php_imap.c?view=log#rev1.260
2008-06-19
--- cve-2008-2829.xml ends here ---
--- cve-2008-3659.xml begins here ---
PHP 5.x -- buffer overflow in the memnstr()
php5
5.2.6_3
Entry for CVE-2008-3659 says:
Buffer overflow in the memnstr function in PHP 4.4.x before
4.4.9 and PHP 5.6 through 5.2.6 allows context-dependent
attackers to cause a denial of service (crash) and possibly
execute arbitrary code via the delimiter argument to the explode
function.
NOTE: the scope of this issue is limited since most
applications would not use an attacker-controlled delimiter, but
local attacks against safe_mode are feasible.
CVE-2008-3659
http://news.php.net/php.cvs/52002
http://www.openwall.com/lists/oss-security/2008/08/08/2
2008-08-05
--- cve-2008-3659.xml ends here ---
--- cve-2008-3660.xml begins here ---
PHP 5.x -- Denial of Service in the FastCGI mode
php5
5.2.6_3
Entry for CVE-2008-3660 says:
PHP 4.4.x before 4.4.9 and PHP 5.6 through 5.2.6, when used
as a FastCGI module, allows remote attackers to cause a denial
of service (crash) via a request with multiple dots preceding
the extension, as demonstrated using foo..php.
CVE-2008-3660
http://news.php.net/php.cvs/51129
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=499987
2008-07-15
--- cve-2008-3660.xml ends here ---
>Release-Note:
>Audit-Trail:
>Unformatted:
From rea-fbsd at codelabs.ru Tue Nov 18 03:30:01 2008
From: rea-fbsd at codelabs.ru (Eygene Ryabinkin)
Date: Tue Nov 18 03:30:14 2008
Subject: ports/128958: [vuxml] [patch] fix CVE-2008-3863 in
print/enscript-letter
Message-ID: <20081118112146.35CA917115@shadow.codelabs.ru>
>Number: 128958
>Category: ports
>Synopsis: [vuxml] [patch] fix CVE-2008-3863 in print/enscript-letter
>Confidential: no
>Severity: serious
>Priority: high
>Responsible: freebsd-ports-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Tue Nov 18 11:30:01 UTC 2008
>Closed-Date:
>Last-Modified:
>Originator: Eygene Ryabinkin
>Release: FreeBSD 7.1-PRERELEASE amd64
>Organization:
Code Labs
>Environment:
System: FreeBSD 7.1-PRERELEASE amd64
>Description:
There is a stack-based overflow in the enscript escape codes handling
code.
Citing by the Secunia's report:
-----
The vulnerability is caused due to a boundary error within the
"read_special_escape()" function in src/psgen.c. This can be exploited
to cause a stack-based buffer overflow by tricking the user into
converting a malicious file.
Successful exploitation allows execution of arbitrary code, but
requires that special escapes processing is enabled with the "-e"
option.
-----
>How-To-Repeat:
http://secunia.com/secunia_research/2008-41/
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3863
>Fix:
The following patch should introduce the fix to the FreeBSD port:
--- 1.6.4_1-to-1.6.4_2-fix-CVE-2008-4306.diff begins here ---
diff -urN ./Makefile ../enscript-letter/Makefile
--- ./Makefile 2008-11-18 13:57:48.000000000 +0300
+++ ../enscript-letter/Makefile 2008-11-18 13:58:02.000000000 +0300
@@ -7,7 +7,7 @@
PORTNAME= enscript
PORTVERSION= 1.6.4
-PORTREVISION= 1
+PORTREVISION= 2
CATEGORIES+= print
MASTER_SITES= http://www.codento.com/people/mtr/genscript/
PKGNAMESUFFIX= -${PAPERSIZE}
diff -urN ./files/patch-CVE-2008-3863-and-4306 ../enscript-letter/files/patch-CVE-2008-3863-and-4306
--- ./files/patch-CVE-2008-3863-and-4306 1970-01-01 03:00:00.000000000 +0300
+++ ../enscript-letter/files/patch-CVE-2008-3863-and-4306 2008-11-18 13:57:08.000000000 +0300
@@ -0,0 +1,94 @@
+Patch for CVE-2008-3863 and CVE-2008-4306
+
+Obtained from: http://cvs.fedoraproject.org/viewvc/devel/enscript/enscript-CVE-2008-3863%2BCVE-2008-4306.patch?revision=1.1
+
+--- src/psgen.c
++++ src/psgen.c 2008-10-29 10:43:08.512598143 +0100
+@@ -24,6 +24,7 @@
+ * Boston, MA 02111-1307, USA.
+ */
+
++#include
+ #include "gsint.h"
+
+ /*
+@@ -124,7 +125,7 @@ struct gs_token_st
+ double xscale;
+ double yscale;
+ int llx, lly, urx, ury; /* Bounding box. */
+- char filename[512];
++ char filename[PATH_MAX];
+ char *skipbuf;
+ unsigned int skipbuf_len;
+ unsigned int skipbuf_pos;
+@@ -135,11 +136,11 @@ struct gs_token_st
+ Color bgcolor;
+ struct
+ {
+- char name[512];
++ char name[PATH_MAX];
+ FontPoint size;
+ InputEncoding encoding;
+ } font;
+- char filename[512];
++ char filename[PATH_MAX];
+ } u;
+ };
+
+@@ -248,7 +249,7 @@ static int do_print = 1;
+ static int user_fontp = 0;
+
+ /* The user ^@font{}-defined font. */
+-static char user_font_name[256];
++static char user_font_name[PATH_MAX];
+ static FontPoint user_font_pt;
+ static InputEncoding user_font_encoding;
+
+@@ -978,7 +979,8 @@ large for page\n"),
+ FATAL ((stderr,
+ _("user font encoding can be only the system's default or `ps'")));
+
+- strcpy (user_font_name, token.u.font.name);
++ memset (user_font_name, 0, sizeof(user_font_name));
++ strncpy (user_font_name, token.u.font.name, sizeof(user_font_name) - 1);
+ user_font_pt.w = token.u.font.size.w;
+ user_font_pt.h = token.u.font.size.h;
+ user_font_encoding = token.u.font.encoding;
+@@ -1444,7 +1446,7 @@ read_special_escape (InputStream *is, To
+ buf[i] = ch;
+ if (i + 1 >= sizeof (buf))
+ FATAL ((stderr, _("too long argument for %s escape:\n%.*s"),
+- escapes[i].name, i, buf));
++ escapes[e].name, i, buf));
+ }
+ buf[i] = '\0';
+
+@@ -1452,7 +1454,8 @@ read_special_escape (InputStream *is, To
+ switch (escapes[e].escape)
+ {
+ case ESC_FONT:
+- strcpy (token->u.font.name, buf);
++ memset (token->u.font.name, 0, sizeof(token->u.font.name));
++ strncpy (token->u.font.name, buf, sizeof(token->u.font.name) - 1);
+
+ /* Check for the default font. */
+ if (strcmp (token->u.font.name, "default") == 0)
+@@ -1465,7 +1468,8 @@ read_special_escape (InputStream *is, To
+ FATAL ((stderr, _("malformed font spec for ^@font escape: %s"),
+ token->u.font.name));
+
+- strcpy (token->u.font.name, cp);
++ memset (token->u.font.name, 0, sizeof(token->u.font.name));
++ strncpy (token->u.font.name, cp, sizeof(token->u.font.name) - 1);
+ xfree (cp);
+ }
+ token->type = tFONT;
+@@ -1544,7 +1548,8 @@ read_special_escape (InputStream *is, To
+ break;
+
+ case ESC_SETFILENAME:
+- strcpy (token->u.filename, buf);
++ memset (token->u.filename, 0, sizeof(token->u.font.name));
++ strncpy (token->u.filename, buf, sizeof(token->u.filename) - 1);
+ token->type = tSETFILENAME;
+ break;
--- 1.6.4_1-to-1.6.4_2-fix-CVE-2008-4306.diff ends here ---
The following VuXML entry should be added:
--- vuln.xml begins here ---
GNU enscript -- multiple vulnerabilities
enscript-letter
enscript-letterdj
enscript-a4
1.6.4_2
Ulf Harnhammar from Secunia Research had discovered stack-based
buffer overflow vulnerability in the GNU enscript code:
Stack-based buffer overflow in the read_special_escape
function in src/psgen.c in GNU Enscript 1.6.1 and 1.6.4 beta,
when the -e (aka special escapes processing) option is enabled,
allows user-assisted remote attackers to execute arbitrary code
via a crafted ASCII file, related to the setfilename
command.
CVE-2008-4306 is a Ubuntu-specific mirror issue for this
vulnerability.
CVE-2008-3863
CVE-2008-4306
http://secunia.com/secunia_research/2008-41/
http://cvs.fedoraproject.org/viewvc//devel/enscript/enscript-CVE-2008-3863+CVE-2008-4306.patch
https://launchpad.net/ubuntu/intrepid/+source/enscript/1.6.4-12ubuntu0.8.10.1
2008-10-22
--- vuln.xml ends here ---
>Release-Note:
>Audit-Trail:
>Unformatted:
From miwi at FreeBSD.org Tue Nov 18 03:50:28 2008
From: miwi at FreeBSD.org (miwi@FreeBSD.org)
Date: Tue Nov 18 03:50:39 2008
Subject: ports/128956: [patch] [vuxml] multiple vulnerabilities in PHP
5.2.6
Message-ID: <200811181150.mAIBoS1J033367@freefall.freebsd.org>
Synopsis: [patch] [vuxml] multiple vulnerabilities in PHP 5.2.6
Responsible-Changed-From-To: freebsd-ports-bugs->miwi
Responsible-Changed-By: miwi
Responsible-Changed-When: Tue Nov 18 11:50:28 UTC 2008
Responsible-Changed-Why:
I'll take it.
http://www.freebsd.org/cgi/query-pr.cgi?pr=128956
From rea-fbsd at codelabs.ru Tue Nov 18 04:00:11 2008
From: rea-fbsd at codelabs.ru (Eygene Ryabinkin)
Date: Tue Nov 18 04:00:20 2008
Subject: ports/128960: [patch] [vuxml] fix chroot issue in the
sysutils/syslog-ng2
Message-ID: <20081118115957.E4FB717116@shadow.codelabs.ru>
>Number: 128960
>Category: ports
>Synopsis: [patch] [vuxml] fix chroot issue in the sysutils/syslog-ng2
>Confidential: no
>Severity: serious
>Priority: high
>Responsible: freebsd-ports-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Tue Nov 18 12:00:09 UTC 2008
>Closed-Date:
>Last-Modified:
>Originator: Eygene Ryabinkin
>Release: FreeBSD 7.1-PRERELEASE amd64
>Organization:
Code Labs
>Environment:
System: FreeBSD 7.1-PRERELEASE amd64
>Description:
It was discovered [1] that syslog-ng 2.0.9 does not call chdir() before
chroot, so this effectively leaking the syslog's startup directory to
the chrooted environment.
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=505791
>How-To-Repeat:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=505791
http://www.openwall.com/lists/oss-security/2008/11/17/3
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5110
Please, note that CVE-2008-5110 is "too new" now -- ID was just created
and no entry seem to be uploaded to the cve.mitre.org yet.
>Fix:
The following patch fixes the things:
--- 2.0.9_1-to-2.0.9_2-fix-CVE-2008-5110.diff begins here ---
diff -urN ./Makefile ../syslog-ng2/Makefile
--- ./Makefile 2008-11-18 14:31:05.000000000 +0300
+++ ../syslog-ng2/Makefile 2008-11-18 14:31:15.000000000 +0300
@@ -7,7 +7,7 @@
PORTNAME= syslog-ng
PORTVERSION= 2.0.9
-PORTREVISION= 1
+PORTREVISION= 2
CATEGORIES= sysutils
MASTER_SITES= http://www.balabit.com/downloads/files/syslog-ng/sources/2.0/src/
PKGNAMESUFFIX= 2
diff -urN ./files/patch-CVE-2008-5110 ../syslog-ng2/files/patch-CVE-2008-5110
--- ./files/patch-CVE-2008-5110 1970-01-01 03:00:00.000000000 +0300
+++ ../syslog-ng2/files/patch-CVE-2008-5110 2008-11-18 14:40:00.000000000 +0300
@@ -0,0 +1,22 @@
+Patch for CVE-2008-5110
+
+Obtained from: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=14;mbox=yes;bug=505791
+Note: was not able to cleanly apply the original patch, so it was recreated
+ by hand using the original submission contents
+
+--- src/main.c.orig 2008-03-23 23:35:27.000000000 +0300
++++ src/main.c 2008-11-18 14:38:13.000000000 +0300
+@@ -275,6 +275,13 @@
+ {
+ if (chroot_dir)
+ {
++ if (chdir(chroot_dir) < 0)
++ {
++ msg_error("Error during chdir() before chroot()",
++ evt_tag_errno(EVT_TAG_OSERROR, errno),
++ NULL);
++ return 0;
++ }
+ if (chroot(chroot_dir) < 0)
+ {
+ msg_error("Error during chroot()",
--- 2.0.9_1-to-2.0.9_2-fix-CVE-2008-5110.diff ends here ---
This issue deserves the following VuXML entry:
--- vuln.xml begins here ---
Syslog-ng -- startup directory leakage in the chroot environment
syslog-ng2
2.0.9_2
Florian Grandel had reported through the Debian bug tracker
that syslong-ng has the security vulnerability associated with
the chroot() call.
I have not had the time to analyze all of syslog-ng code.
But by reading the code section near the chroot call and looking
at strace results I believe that syslog-ng does not chdir to the
chroot jail's location before chrooting into it.
This opens up ways to work around the chroot jail.
CVE-2008-5110
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=505791
http://www.openwall.com/lists/oss-security/2008/11/17/3
2008-11-15
--- vuln.xml ends here ---
>Release-Note:
>Audit-Trail:
>Unformatted:
From rea-fbsd at codelabs.ru Tue Nov 18 04:29:12 2008
From: rea-fbsd at codelabs.ru (Eygene Ryabinkin)
Date: Tue Nov 18 04:29:28 2008
Subject: ports/128956: [patch] [vuxml] multiple vulnerabilities in PHP
5.2.6
In-Reply-To: <4922B371.6070002@quis.cx>
References: <20081118103433.38D5817115@shadow.codelabs.ru>
<4922B371.6070002@quis.cx>
Message-ID:
Jille, good day.
Tue, Nov 18, 2008 at 01:22:09PM +0100, Jille Timmermans wrote:
> I think there is a typo in the vuxml descriptions:
> "PHP 4.4.x before 4.4.9 and PHP 5.6 through 5.2.6"
> (PHP 5.6 doesn't exist (yet))
Yes: it was written in that way at the CVE entry. I had spotted this,
but was not sure how to handle this. Perhaps VuXML entry should really
say "PHP 5.2 through 5.2.6" to avoid reader's confusion.
Thanks for spotting this!
--
Eygene
_ ___ _.--. #
\`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, / # while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / # -- FreeBSD Developers handbook
{_.-``-' {_/ #
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-security/attachments/20081118/dbe0e357/attachment.pgp
From jille at quis.cx Tue Nov 18 04:37:11 2008
From: jille at quis.cx (Jille Timmermans)
Date: Tue Nov 18 04:37:19 2008
Subject: ports/128956: [patch] [vuxml] multiple vulnerabilities in PHP
5.2.6
In-Reply-To:
References: <20081118103433.38D5817115@shadow.codelabs.ru> <4922B371.6070002@quis.cx>
Message-ID: <4922B6F9.2000408@quis.cx>
Good day to you too,
"PHP 5.2 through 5.2.6" makes the most sense.
However, "PHP 5.1 through" or even "PHP 5 through" are also possible.
I don't know much about CVE's; can we provide them feedback for this typo ?
I think the best is to wait for the CVE to get fixed and fix it in the vuxml entry afterwards.
I think you also had that plan ;)
-- Jille
Eygene Ryabinkin wrote:
> Jille, good day.
>
> Tue, Nov 18, 2008 at 01:22:09PM +0100, Jille Timmermans wrote:
>
>> I think there is a typo in the vuxml descriptions:
>> "PHP 4.4.x before 4.4.9 and PHP 5.6 through 5.2.6"
>> (PHP 5.6 doesn't exist (yet))
>>
>
> Yes: it was written in that way at the CVE entry. I had spotted this,
> but was not sure how to handle this. Perhaps VuXML entry should really
> say "PHP 5.2 through 5.2.6" to avoid reader's confusion.
>
> Thanks for spotting this!
>
From jille at quis.cx Tue Nov 18 04:38:06 2008
From: jille at quis.cx (Jille Timmermans)
Date: Tue Nov 18 04:38:14 2008
Subject: ports/128956: [patch] [vuxml] multiple vulnerabilities in PHP
5.2.6
In-Reply-To: <20081118103433.38D5817115@shadow.codelabs.ru>
References: <20081118103433.38D5817115@shadow.codelabs.ru>
Message-ID: <4922B371.6070002@quis.cx>
I think there is a typo in the vuxml descriptions:
"PHP 4.4.x before 4.4.9 and PHP 5.6 through 5.2.6"
(PHP 5.6 doesn't exist (yet))
-- Jille
Eygene Ryabinkin wrote:
>> Number: 128956
>> Category: ports
>> Synopsis: [patch] [vuxml] multiple vulnerabilities in PHP 5.2.6
>> Confidential: no
>> Severity: serious
>> Priority: high
>> Responsible: freebsd-ports-bugs
>> State: open
>> Quarter:
>> Keywords:
>> Date-Required:
>> Class: sw-bug
>> Submitter-Id: current-users
>> Arrival-Date: Tue Nov 18 10:40:00 UTC 2008
>> Closed-Date:
>> Last-Modified:
>> Originator: Eygene Ryabinkin
>> Release: FreeBSD 7.1-PRERELEASE amd64
>> Organization:
>>
> Code Labs
>
>> Environment:
>>
>
> System: FreeBSD 7.1-PRERELEASE amd64
>
>
>> Description:
>>
>
> There are some vulnerabilities in the stock PHP 5.2.6 that were silently
> fixed in the CVS, but after 5.2.6 was out.
>
>
>> How-To-Repeat:
>>
>
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2829
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3659
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3660
>
>
>> Fix:
>>
>
> The following patches should fix all three issues. I had mildly
> tested them in my setups.
> --- 5.2.6_2-to-5.2.6_3-fix-cve-2008-3659.3660.diff begins here ---
> diff -urN ./Makefile ../php5/Makefile
> --- ./Makefile 2008-11-18 11:49:16.000000000 +0300
> +++ ../php5/Makefile 2008-11-18 11:49:27.000000000 +0300
> @@ -7,7 +7,7 @@
>
> PORTNAME= php5
> PORTVERSION= 5.2.6
> -PORTREVISION?= 2
> +PORTREVISION?= 3
> CATEGORIES?= lang devel www
> MASTER_SITES= ${MASTER_SITE_PHP}
> MASTER_SITE_SUBDIR= distributions
> diff -urN ./files/patch-CVE-2008-3659 ../php5/files/patch-CVE-2008-3659
> --- ./files/patch-CVE-2008-3659 1970-01-01 03:00:00.000000000 +0300
> +++ ../php5/files/patch-CVE-2008-3659 2008-11-18 11:49:55.000000000 +0300
> @@ -0,0 +1,27 @@
> +Patch for CVE-2008-3659.
> +
> +Obtained from: http://cvs.php.net/viewvc.cgi/ZendEngine2/zend_operators.h?r1=1.94.2.4.2.11&r2=1.94.2.4.2.12&view=patch
> +See also: http://news.php.net/php.cvs/52002
> +See also: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3659
> +
> +--- Zend/zend_operators.h 2007/12/31 07:20:03 1.94.2.4.2.11
> ++++ Zend/zend_operators.h 2008/08/05 20:11:17 1.94.2.4.2.12
> +@@ -17,7 +17,7 @@
> + +----------------------------------------------------------------------+
> + */
> +
> +-/* $Id: zend_operators.h,v 1.94.2.4.2.11 2007/12/31 07:20:03 sebastian Exp $ */
> ++/* $Id: zend_operators.h,v 1.94.2.4.2.12 2008/08/05 20:11:17 stas Exp $ */
> +
> + #ifndef ZEND_OPERATORS_H
> + #define ZEND_OPERATORS_H
> +@@ -220,6 +220,9 @@
> + char *p = haystack;
> + char ne = needle[needle_len-1];
> +
> ++ if(needle_len > end-haystack) {
> ++ return NULL;
> ++ }
> + end -= needle_len;
> +
> + while (p <= end) {
> diff -urN ./files/patch-CVE-2008-3660 ../php5/files/patch-CVE-2008-3660
> --- ./files/patch-CVE-2008-3660 1970-01-01 03:00:00.000000000 +0300
> +++ ../php5/files/patch-CVE-2008-3660 2008-11-18 12:15:23.000000000 +0300
> @@ -0,0 +1,82 @@
> +Patch for CVE-2008-3660
> +
> +Obtained from: http://cvs.php.net/viewvc.cgi/php-src/sapi/cgi/cgi_main.c?r1=1.267.2.15.2.57&r2=1.267.2.15.2.58&view=patch
> +See also: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3660
> +See also: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=499987
> +Notes: removed 'Id' hunk and reapplied this patch for the php-5.2.6
> +
> +--- sapi/cgi/cgi_main.c.orig 2008-04-09 13:16:40.000000000 +0400
> ++++ sapi/cgi/cgi_main.c 2008-11-18 12:08:10.000000000 +0300
> +@@ -765,6 +765,39 @@
> + }
> + /* }}} */
> +
> ++/* {{{ is_valid_path
> ++ *
> ++ * some server configurations allow '..' to slip through in the
> ++ * translated path. We'll just refuse to handle such a path.
> ++ */
> ++static int is_valid_path(const char *path)
> ++{
> ++ const char *p;
> ++
> ++ if (!path) {
> ++ return 0;
> ++ }
> ++ p = strstr(path, "..");
> ++ if (p) {
> ++ if ((p == path || IS_SLASH(*(p-1))) &&
> ++ (*(p+2) == 0 || IS_SLASH(*(p+2)))) {
> ++ return 0;
> ++ }
> ++ while (1) {
> ++ p = strstr(p+1, "..");
> ++ if (!p) {
> ++ break;
> ++ }
> ++ if (IS_SLASH(*(p-1)) &&
> ++ (*(p+2) == 0 || IS_SLASH(*(p+2)))) {
> ++ return 0;
> ++ }
> ++ }
> ++ }
> ++ return 1;
> ++}
> ++/* }}} */
> ++
> + /* {{{ init_request_info
> +
> + initializes request_info structure
> +@@ -1061,9 +1094,7 @@
> + if (pt) {
> + efree(pt);
> + }
> +- /* some server configurations allow '..' to slip through in the
> +- translated path. We'll just refuse to handle such a path. */
> +- if (script_path_translated && !strstr(script_path_translated, "..")) {
> ++ if (is_valid_path(script_path_translated)) {
> + SG(request_info).path_translated = estrdup(script_path_translated);
> + }
> + } else {
> +@@ -1094,9 +1125,7 @@
> + } else {
> + SG(request_info).request_uri = env_script_name;
> + }
> +- /* some server configurations allow '..' to slip through in the
> +- translated path. We'll just refuse to handle such a path. */
> +- if (script_path_translated && !strstr(script_path_translated, "..")) {
> ++ if (is_valid_path(script_path_translated)) {
> + SG(request_info).path_translated = estrdup(script_path_translated);
> + }
> + free(real_path);
> +@@ -1114,9 +1143,7 @@
> + script_path_translated = env_path_translated;
> + }
> + #endif
> +- /* some server configurations allow '..' to slip through in the
> +- translated path. We'll just refuse to handle such a path. */
> +- if (script_path_translated && !strstr(script_path_translated, "..")) {
> ++ if (is_valid_path(script_path_translated)) {
> + SG(request_info).path_translated = estrdup(script_path_translated);
> + }
> + #if ENABLE_PATHINFO_CHECK
> --- 5.2.6_2-to-5.2.6_3-fix-cve-2008-3659.3660.diff ends here ---
>
> --- imap-5.2.6_2-to-5.2.6_3-fix-cve-2008-2829.diff begins here ---
> diff -urN ./files/patch-CVE-2008-2829 ../php5-imap/files/patch-CVE-2008-2829
> --- ./files/patch-CVE-2008-2829 1970-01-01 03:00:00.000000000 +0300
> +++ ../php5-imap/files/patch-CVE-2008-2829 2008-11-18 13:20:19.000000000 +0300
> @@ -0,0 +1,282 @@
> +Fix for CVE-2008-2829
> +
> +Obtained from: http://cvs.php.net/viewvc.cgi/php-src/ext/imap/php_imap.c?r1=1.259&r2=1.260&view=patch
> +Notes: reapplied to php-5.6.2, skipped 'Id' hunk and modified hunk marked
> + '-3213,7 +3214,7'.
> +
> +--- php_imap.c.orig 2008-04-17 15:04:49.000000000 +0400
> ++++ php_imap.c 2008-11-18 13:03:02.000000000 +0300
> +@@ -40,6 +40,7 @@
> + #include "ext/standard/php_string.h"
> + #include "ext/standard/info.h"
> + #include "ext/standard/file.h"
> ++#include "ext/standard/php_smart_str.h"
> +
> + #ifdef ERROR
> + #undef ERROR
> +@@ -66,10 +67,11 @@
> + #define SENDBUFLEN 16385
> + #endif
> +
> ++
> + static void _php_make_header_object(zval *myzvalue, ENVELOPE *en TSRMLS_DC);
> + static void _php_imap_add_body(zval *arg, BODY *body TSRMLS_DC);
> +-static void _php_imap_parse_address(ADDRESS *addresslist, char **fulladdress, zval *paddress TSRMLS_DC);
> +-static int _php_imap_address_size(ADDRESS *addresslist);
> ++static char* _php_imap_parse_address(ADDRESS *addresslist, zval *paddress TSRMLS_DC);
> ++static char* _php_rfc822_write_address(ADDRESS *addresslist TSRMLS_DC);
> +
> + /* the gets we use */
> + static char *php_mail_gets(readfn_t f, void *stream, unsigned long size, GETS_DATA *md);
> +@@ -2109,7 +2111,7 @@
> + {
> + zval **mailbox, **host, **personal;
> + ADDRESS *addr;
> +- char string[MAILTMPLEN];
> ++ char *string;
> +
> + if (ZEND_NUM_ARGS() != 3 || zend_get_parameters_ex(3, &mailbox, &host, &personal) == FAILURE) {
> + ZEND_WRONG_PARAM_COUNT();
> +@@ -2137,13 +2139,12 @@
> + addr->error=NIL;
> + addr->adl=NIL;
> +
> +- if (_php_imap_address_size(addr) >= MAILTMPLEN) {
> ++ string = _php_rfc822_write_address(addr TSRMLS_CC);
> ++ if (string) {
> ++ RETVAL_STRING(string, 0);
> ++ } else {
> + RETURN_FALSE;
> + }
> +-
> +- string[0]='\0';
> +- rfc822_write_address(string, addr);
> +- RETVAL_STRING(string, 1);
> + }
> + /* }}} */
> +
> +@@ -2873,7 +2874,7 @@
> + zval **streamind, **sequence, **pflags;
> + pils *imap_le_struct;
> + zval *myoverview;
> +- char address[MAILTMPLEN];
> ++ char *address;
> + long status, flags=0L;
> + int myargc = ZEND_NUM_ARGS();
> +
> +@@ -2908,17 +2909,19 @@
> + if (env->subject) {
> + add_property_string(myoverview, "subject", env->subject, 1);
> + }
> +- if (env->from && _php_imap_address_size(env->from) < MAILTMPLEN) {
> ++ if (env->from) {
> + env->from->next=NULL;
> +- address[0] = '\0';
> +- rfc822_write_address(address, env->from);
> +- add_property_string(myoverview, "from", address, 1);
> ++ address =_php_rfc822_write_address(env->from TSRMLS_CC);
> ++ if (address) {
> ++ add_property_string(myoverview, "from", address, 0);
> ++ }
> + }
> +- if (env->to && _php_imap_address_size(env->to) < MAILTMPLEN) {
> ++ if (env->to) {
> + env->to->next = NULL;
> +- address[0] = '\0';
> +- rfc822_write_address(address, env->to);
> +- add_property_string(myoverview, "to", address, 1);
> ++ address = _php_rfc822_write_address(env->to TSRMLS_CC);
> ++ if (address) {
> ++ add_property_string(myoverview, "to", address, 0);
> ++ }
> + }
> + if (env->date) {
> + add_property_string(myoverview, "date", env->date, 1);
> +@@ -3858,6 +3861,43 @@
> + /* }}} */
> +
> + /* Support Functions */
> ++
> ++#ifdef HAVE_RFC822_OUTPUT_ADDRESS_LIST
> ++/* {{{ _php_rfc822_soutr
> ++ */
> ++static long _php_rfc822_soutr (void *stream, char *string)
> ++{
> ++ smart_str *ret = (smart_str*)stream;
> ++ int len = strlen(string);
> ++
> ++ smart_str_appendl(ret, string, len);
> ++ return LONGT;
> ++}
> ++
> ++/* }}} */
> ++
> ++/* {{{ _php_rfc822_write_address
> ++ */
> ++static char* _php_rfc822_write_address(ADDRESS *addresslist TSRMLS_DC)
> ++{
> ++ char address[MAILTMPLEN];
> ++ smart_str ret = {0};
> ++ RFC822BUFFER buf;
> ++
> ++ buf.beg = address;
> ++ buf.cur = buf.beg;
> ++ buf.end = buf.beg + sizeof(address) - 1;
> ++ buf.s = &ret;
> ++ buf.f = _php_rfc822_soutr;
> ++ rfc822_output_address_list(&buf, addresslist, 0, NULL);
> ++ rfc822_output_flush(&buf);
> ++ smart_str_0(&ret);
> ++ return ret.c;
> ++}
> ++/* }}} */
> ++
> ++#else
> ++
> + /* {{{ _php_imap_get_address_size
> + */
> + static int _php_imap_address_size (ADDRESS *addresslist)
> +@@ -3887,26 +3927,33 @@
> +
> + /* }}} */
> +
> ++/* {{{ _php_rfc822_write_address
> ++ */
> ++static char* _php_rfc822_write_address(ADDRESS *addresslist TSRMLS_DC)
> ++{
> ++ char address[SENDBUFLEN];
> +
> ++ if (_php_imap_address_size(addresslist) >= SENDBUFLEN) {
> ++ php_error_docref(NULL TSRMLS_CC, E_ERROR, "Address buffer overflow");
> ++ return NULL;
> ++ }
> ++ address[0] = 0;
> ++ rfc822_write_address(address, addresslist);
> ++ return estrdup(address);
> ++}
> ++/* }}} */
> ++#endif
> + /* {{{ _php_imap_parse_address
> + */
> +-static void _php_imap_parse_address (ADDRESS *addresslist, char **fulladdress, zval *paddress TSRMLS_DC)
> ++static char* _php_imap_parse_address (ADDRESS *addresslist, zval *paddress TSRMLS_DC)
> + {
> ++ char *fulladdress;
> + ADDRESS *addresstmp;
> + zval *tmpvals;
> +- char *tmpstr;
> +- int len=0;
> +
> + addresstmp = addresslist;
> +
> +- if ((len = _php_imap_address_size(addresstmp))) {
> +- tmpstr = (char *) pemalloc(len + 1, 1);
> +- tmpstr[0] = '\0';
> +- rfc822_write_address(tmpstr, addresstmp);
> +- *fulladdress = tmpstr;
> +- } else {
> +- *fulladdress = NULL;
> +- }
> ++ fulladdress = _php_rfc822_write_address(addresstmp TSRMLS_CC);
> +
> + addresstmp = addresslist;
> + do {
> +@@ -3918,6 +3965,7 @@
> + if (addresstmp->host) add_property_string(tmpvals, "host", addresstmp->host, 1);
> + add_next_index_object(paddress, tmpvals TSRMLS_CC);
> + } while ((addresstmp = addresstmp->next));
> ++ return fulladdress;
> + }
> + /* }}} */
> +
> +@@ -3944,10 +3992,9 @@
> + if (en->to) {
> + MAKE_STD_ZVAL(paddress);
> + array_init(paddress);
> +- _php_imap_parse_address(en->to, &fulladdress, paddress TSRMLS_CC);
> ++ fulladdress = _php_imap_parse_address(en->to, paddress TSRMLS_CC);
> + if (fulladdress) {
> +- add_property_string(myzvalue, "toaddress", fulladdress, 1);
> +- free(fulladdress);
> ++ add_property_string(myzvalue, "toaddress", fulladdress, 0);
> + }
> + add_assoc_object(myzvalue, "to", paddress TSRMLS_CC);
> + }
> +@@ -3955,10 +4002,9 @@
> + if (en->from) {
> + MAKE_STD_ZVAL(paddress);
> + array_init(paddress);
> +- _php_imap_parse_address(en->from, &fulladdress, paddress TSRMLS_CC);
> ++ fulladdress = _php_imap_parse_address(en->from, paddress TSRMLS_CC);
> + if (fulladdress) {
> +- add_property_string(myzvalue, "fromaddress", fulladdress, 1);
> +- free(fulladdress);
> ++ add_property_string(myzvalue, "fromaddress", fulladdress, 0);
> + }
> + add_assoc_object(myzvalue, "from", paddress TSRMLS_CC);
> + }
> +@@ -3966,10 +4012,9 @@
> + if (en->cc) {
> + MAKE_STD_ZVAL(paddress);
> + array_init(paddress);
> +- _php_imap_parse_address(en->cc, &fulladdress, paddress TSRMLS_CC);
> ++ fulladdress = _php_imap_parse_address(en->cc, paddress TSRMLS_CC);
> + if (fulladdress) {
> +- add_property_string(myzvalue, "ccaddress", fulladdress, 1);
> +- free(fulladdress);
> ++ add_property_string(myzvalue, "ccaddress", fulladdress, 0);
> + }
> + add_assoc_object(myzvalue, "cc", paddress TSRMLS_CC);
> + }
> +@@ -3977,10 +4022,9 @@
> + if (en->bcc) {
> + MAKE_STD_ZVAL(paddress);
> + array_init(paddress);
> +- _php_imap_parse_address(en->bcc, &fulladdress, paddress TSRMLS_CC);
> ++ fulladdress = _php_imap_parse_address(en->bcc, paddress TSRMLS_CC);
> + if (fulladdress) {
> +- add_property_string(myzvalue, "bccaddress", fulladdress, 1);
> +- free(fulladdress);
> ++ add_property_string(myzvalue, "bccaddress", fulladdress, 0);
> + }
> + add_assoc_object(myzvalue, "bcc", paddress TSRMLS_CC);
> + }
> +@@ -3988,10 +4032,9 @@
> + if (en->reply_to) {
> + MAKE_STD_ZVAL(paddress);
> + array_init(paddress);
> +- _php_imap_parse_address(en->reply_to, &fulladdress, paddress TSRMLS_CC);
> ++ fulladdress = _php_imap_parse_address(en->reply_to, paddress TSRMLS_CC);
> + if (fulladdress) {
> +- add_property_string(myzvalue, "reply_toaddress", fulladdress, 1);
> +- free(fulladdress);
> ++ add_property_string(myzvalue, "reply_toaddress", fulladdress, 0);
> + }
> + add_assoc_object(myzvalue, "reply_to", paddress TSRMLS_CC);
> + }
> +@@ -3999,10 +4042,9 @@
> + if (en->sender) {
> + MAKE_STD_ZVAL(paddress);
> + array_init(paddress);
> +- _php_imap_parse_address(en->sender, &fulladdress, paddress TSRMLS_CC);
> ++ fulladdress = _php_imap_parse_address(en->sender, paddress TSRMLS_CC);
> + if (fulladdress) {
> +- add_property_string(myzvalue, "senderaddress", fulladdress, 1);
> +- free(fulladdress);
> ++ add_property_string(myzvalue, "senderaddress", fulladdress, 0);
> + }
> + add_assoc_object(myzvalue, "sender", paddress TSRMLS_CC);
> + }
> +@@ -4010,10 +4052,9 @@
> + if (en->return_path) {
> + MAKE_STD_ZVAL(paddress);
> + array_init(paddress);
> +- _php_imap_parse_address(en->return_path, &fulladdress, paddress TSRMLS_CC);
> ++ fulladdress = _php_imap_parse_address(en->return_path, paddress TSRMLS_CC);
> + if (fulladdress) {
> +- add_property_string(myzvalue, "return_pathaddress", fulladdress, 1);
> +- free(fulladdress);
> ++ add_property_string(myzvalue, "return_pathaddress", fulladdress, 0);
> + }
> + add_assoc_object(myzvalue, "return_path", paddress TSRMLS_CC);
> + }
> --- imap-5.2.6_2-to-5.2.6_3-fix-cve-2008-2829.diff ends here ---
>
> I assume that they all will go in one shot, so the following VuXML
> entries use 5.2.6_3 as the first version where issues were fixed.
> --- cve-2008-2829.xml begins here ---
>
> PHP 5.x -- Denial of Service and possible arbitrary code execution in the IMAP extension
>
>
> php5-imap
> 5.2.6_3
>
>
>
>
> Entry for CVE-2008-2829 says:
>
> php_imap.c in PHP 5.2.5, 5.2.6, 4.x, and other versions, uses
> obsolete API calls that allow context-dependent attackers to
> cause a denial of service (crash) and possibly execute arbitrary
> code via a long IMAP request, which triggers an "rfc822.c legacy
> routine buffer overflow" error message.
>
>
>
>
> CVE-2008-2829
> http://bugs.php.net/bug.php?id=42862
> http://bugs.php.net/bug.php?id=40925
> http://cvs.php.net/viewvc.cgi/php-src/ext/imap/php_imap.c?view=log#rev1.260
>
>
> 2008-06-19
>
>
> --- cve-2008-2829.xml ends here ---
>
> --- cve-2008-3659.xml begins here ---
>
> PHP 5.x -- buffer overflow in the memnstr()
>
>
> php5
> 5.2.6_3
>
>
>
>
> Entry for CVE-2008-3659 says:
>
> Buffer overflow in the memnstr function in PHP 4.4.x before
> 4.4.9 and PHP 5.6 through 5.2.6 allows context-dependent
> attackers to cause a denial of service (crash) and possibly
> execute arbitrary code via the delimiter argument to the explode
> function.
> NOTE: the scope of this issue is limited since most
> applications would not use an attacker-controlled delimiter, but
> local attacks against safe_mode are feasible.
>
>
>
>
> CVE-2008-3659
> http://news.php.net/php.cvs/52002
> http://www.openwall.com/lists/oss-security/2008/08/08/2
>
>
> 2008-08-05
>
>
> --- cve-2008-3659.xml ends here ---
>
> --- cve-2008-3660.xml begins here ---
>
> PHP 5.x -- Denial of Service in the FastCGI mode
>
>
> php5
> 5.2.6_3
>
>
>
>
> Entry for CVE-2008-3660 says:
>
> PHP 4.4.x before 4.4.9 and PHP 5.6 through 5.2.6, when used
> as a FastCGI module, allows remote attackers to cause a denial
> of service (crash) via a request with multiple dots preceding
> the extension, as demonstrated using foo..php.
>
>
>
>
> CVE-2008-3660
> http://news.php.net/php.cvs/51129
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=499987
>
>
> 2008-07-15
>
>
> --- cve-2008-3660.xml ends here ---
>
>> Release-Note:
>> Audit-Trail:
>> Unformatted:
>>
> _______________________________________________
> freebsd-security@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-security
> To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"
>
From edwin at FreeBSD.org Tue Nov 18 03:30:13 2008
From: edwin at FreeBSD.org (edwin@FreeBSD.org)
Date: Tue Nov 18 04:43:45 2008
Subject: ports/128958: [vuxml] [patch] fix CVE-2008-3863 in
print/enscript-letter
Message-ID: <200811181130.mAIBUCsE015052@freefall.freebsd.org>
Synopsis: [vuxml] [patch] fix CVE-2008-3863 in print/enscript-letter
Responsible-Changed-From-To: freebsd-ports-bugs->rafan
Responsible-Changed-By: edwin
Responsible-Changed-When: Tue Nov 18 11:30:12 UTC 2008
Responsible-Changed-Why:
Over to maintainer (via the GNATS Auto Assign Tool)
http://www.freebsd.org/cgi/query-pr.cgi?pr=128958
From edwin at FreeBSD.org Tue Nov 18 04:00:30 2008
From: edwin at FreeBSD.org (edwin@FreeBSD.org)
Date: Tue Nov 18 04:43:53 2008
Subject: ports/128960: [patch] [vuxml] fix chroot issue in the
sysutils/syslog-ng2
Message-ID: <200811181200.mAIC0UeQ039430@freefall.freebsd.org>
Synopsis: [patch] [vuxml] fix chroot issue in the sysutils/syslog-ng2
State-Changed-From-To: open->feedback
State-Changed-By: edwin
State-Changed-When: Tue Nov 18 12:00:30 UTC 2008
State-Changed-Why:
Awaiting maintainers feedback (via the GNATS Auto Assign Tool)
http://www.freebsd.org/cgi/query-pr.cgi?pr=128960
From rea-fbsd at codelabs.ru Tue Nov 18 06:04:34 2008
From: rea-fbsd at codelabs.ru (Eygene Ryabinkin)
Date: Tue Nov 18 06:04:43 2008
Subject: ports/128956: [patch] [vuxml] multiple vulnerabilities in PHP
5.2.6
In-Reply-To: <4922B6F9.2000408@quis.cx>
References: <20081118103433.38D5817115@shadow.codelabs.ru>
<4922B371.6070002@quis.cx>
<4922B6F9.2000408@quis.cx>
Message-ID: <9a6isDG2HABVFiTQKRYgHLbugj0@N7cbPDipnvOyJMD9YzFbYf8QNqE>
Steven, CVE-supporters, good day.
Today I was submitted FreeBSD's VuXML entry for CVE-2008-3659 and it
seem to be errorneously saying about "PHP 5.6". Could you please try to
follow the discuission and say something about the entry's description
text?
Tue, Nov 18, 2008 at 01:37:13PM +0100, Jille Timmermans wrote:
> "PHP 5.2 through 5.2.6" makes the most sense.
> However, "PHP 5.1 through" or even "PHP 5 through" are also possible.
I had glanced over the PHP's CVS repository: the code in question exists
even for the PHP 5.0 branchpoint (source line 128 and below):
http://cvs.php.net/viewvc.cgi/ZendEngine2/zend_operators.h?revision=1.88&view=markup&pathrev=PHP_5_0
My built-in history tracer tells me the following story:
1. Current code traces back to the zend_operators.h, rev 1.72,
http://cvs.php.net/viewvc.cgi/ZendEngine2/zend_operators.h?view=log#rev1.72
2. The function was moved to ZendEngine2/zend_operators.h from
ext/standard/php_string.h, rev 1.74,
http://cvs.php.net/viewvc.cgi/php-src/ext/standard/php_string.h?view=log#rev1.74
3. Vulnerable code seem to be here since rev 1.40:
http://cvs.php.net/viewvc.cgi/php-src/ext/standard/php_string.h?r1=1.39&r2=1.40&view=patch
So the issue seem to be here since some 4.0.x or even 3.x.
> I don't know much about CVE's; can we provide them feedback for this typo ?
>
> I think the best is to wait for the CVE to get fixed and fix it
> in the vuxml entry afterwards.
Yes, it will be the best thing. So, gentlemen from the CVE maintainers
team, it seems that the entry for the CVE-2008-3659 should be fixed by
saying "PHP 5 through 5.2.6" -- the bug seem to be existed all over the
lifetime for the 5.x branch.
> I think you also had that plan ;)
Sort of ;))
Thanks to everyone!
--
Eygene
_ ___ _.--. #
\`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, / # while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / # -- FreeBSD Developers handbook
{_.-``-' {_/ #
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-security/attachments/20081118/56b70571/attachment.pgp
From rea-fbsd at codelabs.ru Tue Nov 18 07:53:12 2008
From: rea-fbsd at codelabs.ru (Eygene Ryabinkin)
Date: Tue Nov 18 07:53:18 2008
Subject: ports/128956: [patch] [vuxml] multiple vulnerabilities in PHP
5.2.6
In-Reply-To:
References: <20081118103433.38D5817115@shadow.codelabs.ru>
<4922B371.6070002@quis.cx>
<4922B6F9.2000408@quis.cx>
<9a6isDG2HABVFiTQKRYgHLbugj0@N7cbPDipnvOyJMD9YzFbYf8QNqE>
Message-ID:
Skipped content of type multipart/mixed-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-security/attachments/20081118/157c3749/attachment.pgp
From coley at linus.mitre.org Tue Nov 18 07:55:45 2008
From: coley at linus.mitre.org (Steven M. Christey)
Date: Tue Nov 18 08:05:54 2008
Subject: ports/128956: [patch] [vuxml] multiple vulnerabilities in PHP
5.2.6
In-Reply-To: <9a6isDG2HABVFiTQKRYgHLbugj0@N7cbPDipnvOyJMD9YzFbYf8QNqE>
References: <20081118103433.38D5817115@shadow.codelabs.ru>
<4922B371.6070002@quis.cx>
<4922B6F9.2000408@quis.cx>
<9a6isDG2HABVFiTQKRYgHLbugj0@N7cbPDipnvOyJMD9YzFbYf8QNqE>
Message-ID:
On Tue, 18 Nov 2008, Eygene Ryabinkin wrote:
> Steven, CVE-supporters, good day.
>
> Today I was submitted FreeBSD's VuXML entry for CVE-2008-3659 and it
> seem to be errorneously saying about "PHP 5.6". Could you please try to
> follow the discuission and say something about the entry's description
> text?
It's pretty clear that the description was a typo. It doesn't follow our
typical CVE description style of escalating versions when we list version
ranges. Most likely I introduced this typo in the original description.
I've internally changed it to "5.x through 5.2.6." This will show up on
the public CVE web site within a day or two.
Thank you for informing us!
- Steve
From rafan at FreeBSD.org Tue Nov 18 08:04:11 2008
From: rafan at FreeBSD.org (rafan@FreeBSD.org)
Date: Tue Nov 18 10:14:16 2008
Subject: ports/128958: [vuxml] [patch] fix CVE-2008-3863 in
print/enscript-letter
Message-ID: <200811181604.mAIG4B5N026423@freefall.freebsd.org>
Synopsis: [vuxml] [patch] fix CVE-2008-3863 in print/enscript-letter
State-Changed-From-To: open->closed
State-Changed-By: rafan
State-Changed-When: Tue Nov 18 16:04:10 UTC 2008
State-Changed-Why:
Committed, with minor changes. Thanks!
http://www.freebsd.org/cgi/query-pr.cgi?pr=128958
From coley at linus.mitre.org Tue Nov 18 11:51:06 2008
From: coley at linus.mitre.org (Steven M. Christey)
Date: Tue Nov 18 12:03:28 2008
Subject: ports/128956: [patch] [vuxml] multiple vulnerabilities in PHP
5.2.6
In-Reply-To:
References: <20081118103433.38D5817115@shadow.codelabs.ru>
<4922B371.6070002@quis.cx>
<4922B6F9.2000408@quis.cx>
<9a6isDG2HABVFiTQKRYgHLbugj0@N7cbPDipnvOyJMD9YzFbYf8QNqE>
Message-ID:
> So, the VuXML entry should be changed accordingly. New content is
> attached.
Just for my own understanding, did the erroneous CVE description cause any
extra work on your part? What if the desc had only said "5.2 through
5.2.6" at first?
I'm asking because I'm trying to understandind how people use CVE and what
impact our errors might have on others.
Thanks,
Steve
From rea-fbsd at codelabs.ru Wed Nov 19 01:13:08 2008
From: rea-fbsd at codelabs.ru (Eygene Ryabinkin)
Date: Wed Nov 19 01:13:15 2008
Subject: ports/128956: [patch] [vuxml] multiple vulnerabilities in PHP
5.2.6
In-Reply-To:
References: <20081118103433.38D5817115@shadow.codelabs.ru>
<4922B371.6070002@quis.cx>
<4922B6F9.2000408@quis.cx>
<9a6isDG2HABVFiTQKRYgHLbugj0@N7cbPDipnvOyJMD9YzFbYf8QNqE>
Message-ID:
Steven,
Tue, Nov 18, 2008 at 02:50:59PM -0500, Steven M. Christey wrote:
> > So, the VuXML entry should be changed accordingly. New content is
> > attached.
>
> Just for my own understanding, did the erroneous CVE description cause any
> extra work on your part?
No "extra" work. I had just copied the description from CVE and forgot
to change errorneous "5.6" to something more sane. Jille was kind to
point me to this. But it was not clear where in 5.x line the error was
introduced. I had crawled via the PHP CVS and had found that it was
there for the whole 5.x line.
> What if the desc had only said "5.2 through 5.2.6" at first?
I think I will ask myself something like "OK, but what about PHP 5.0 and
5.1? Are they vulnerable?" In principle, I _had_ asked myself about it
and had traced the code via sources back to at least 4.x, so I had
written '<=5.2.6_3' as the vulnerable version specification the VuXML
entry. I just forgot to change the description.
> I'm asking because I'm trying to understandind how people use CVE and what
> impact our errors might have on others.
It may vary, of course. Typically, I am trying to validate CVE
descriptions via some other sources, most used are vendor changelogs
and original advisories. Source code crawling is good too, but it
may be unavailable or a bit uneasy. I think that generally people
tend to trust CVE entries, but checking is always good ;))
--
Eygene
_ ___ _.--. #
\`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, / # while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / # -- FreeBSD Developers handbook
{_.-``-' {_/ #
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-security/attachments/20081119/bf771a4d/attachment.pgp
From rea-fbsd at codelabs.ru Wed Nov 19 05:21:01 2008
From: rea-fbsd at codelabs.ru (Eygene Ryabinkin)
Date: Wed Nov 19 05:21:08 2008
Subject: Plaintext recovery attack in SSH, discovered by CPNI?
Message-ID: <6p2tlso0g3Xi5suHfErE3rcPs54@Mr6N54GlMnGhD+RQ1Yhx+24IxLk>
Good day.
Just came across the following list in the oss-security list:
http://www.cpni.gov.uk/Docs/Vulnerability_Advisory_SSH.txt
People are saying that this vulnerability was tested for Debian's ;))
OpenSSH 4.7p1, but they generally believe that any RFC-compliant
implementation should have this if CBC mode is used. The advisory says
that CTR mode is safe, but I see that at least for FreeBSD's OpenSSH
(OpenSSH_5.1p1) still uses various ciphers in the CBC mode as the
preferential ones. Perhaps we should just change the default
ciphersuites order?
So, it is interesting what OpenSSH developers can tell about this:
I had seen no words about this at http://openssh.org/security.html
and relese notes, so if you can -- please, comment on this.
Thanks!
--
Eygene
_ ___ _.--. #
\`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, / # while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / # -- FreeBSD Developers handbook
{_.-``-' {_/ #
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-security/attachments/20081119/896bce0e/attachment.pgp
From rea-fbsd at codelabs.ru Wed Nov 19 05:23:24 2008
From: rea-fbsd at codelabs.ru (Eygene Ryabinkin)
Date: Wed Nov 19 05:23:31 2008
Subject: Plaintext recovery attack in SSH, discovered by CPNI?
In-Reply-To: <6p2tlso0g3Xi5suHfErE3rcPs54@Mr6N54GlMnGhD+RQ1Yhx+24IxLk>
References: <6p2tlso0g3Xi5suHfErE3rcPs54@Mr6N54GlMnGhD+RQ1Yhx+24IxLk>
Message-ID:
Wed, Nov 19, 2008 at 04:20:58PM +0300, Eygene Ryabinkin wrote:
> Just came across the following list in the oss-security list:
^^^^
Err, wanted to say "link" ;))
--
Eygene
_ ___ _.--. #
\`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, / # while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / # -- FreeBSD Developers handbook
{_.-``-' {_/ #
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-security/attachments/20081119/19a7a3c4/attachment.pgp
From rea-fbsd at codelabs.ru Wed Nov 19 12:50:02 2008
From: rea-fbsd at codelabs.ru (Eygene Ryabinkin)
Date: Wed Nov 19 12:50:10 2008
Subject: ports/128998: [vuxml] document vulnerabilities in textproc/libxml2
Message-ID: <20081119204101.5FBD7F181F@phoenix.codelabs.ru>
>Number: 128998
>Category: ports
>Synopsis: [vuxml] document vulnerabilities in textproc/libxml2
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: freebsd-ports-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Wed Nov 19 20:50:01 UTC 2008
>Closed-Date:
>Last-Modified:
>Originator: Eygene Ryabinkin
>Release: FreeBSD 7.1-PRERELEASE i386
>Organization:
Code Labs
>Environment:
System: FreeBSD 7.1-PRERELEASE i386
>Description:
The fix for the CVE-2008-4225 and CVE-2008-4226 was commited to the
textproc/libxml2 just an hour ago, but vulnerabilities seem to be left
undocumented. At least I was not able to find the corresponding PR and
reporting channels are not clear from the commit comment.
>How-To-Repeat:
http://secunia.com/Advisories/32773/
http://www.freebsd.org/cgi/cvsweb.cgi/ports/textproc/libxml2/Makefile
>Fix:
The following VuXML entry should be evaluated and added:
--- vuln.xml begins here ---
libxml2 -- two integer overflow vulnerabilities
libxml2
2.6.32_2
Secunia reports:
Two vulnerabilities have been reported in Libxml2,
which can be exploited by malicious people to cause a
Denial of Service or to potentially compromise an
application using the library.
- An integer overflow error in the
“xmlSAX2Characters()” function can be
exploited to trigger a memory corruption via a specially
crafted XML file. Successful exploitation may allow
execution of arbitrary code, but requires e.g. that the
user is tricked into processing an overly large XML
file (2GB or more).
- An integer overflow error in the
“xmlBufferResize()” function can be exploited
to trigger the execution of an infinite loop.
CVE-2008-4225
CVE-2008-4226
http://secunia.com/Advisories/32773/
https://bugzilla.redhat.com/show_bug.cgi?id=470466
https://bugzilla.redhat.com/show_bug.cgi?id=470480
2008-11-07
--- vuln.xml ends here ---
>Release-Note:
>Audit-Trail:
>Unformatted:
From edwin at FreeBSD.org Wed Nov 19 12:50:18 2008
From: edwin at FreeBSD.org (edwin@FreeBSD.org)
Date: Wed Nov 19 13:05:47 2008
Subject: ports/128998: [vuxml] document vulnerabilities in
textproc/libxml2
Message-ID: <200811192050.mAJKoHo1057543@freefall.freebsd.org>
Synopsis: [vuxml] document vulnerabilities in textproc/libxml2
Responsible-Changed-From-To: freebsd-ports-bugs->gnome
Responsible-Changed-By: edwin
Responsible-Changed-When: Wed Nov 19 20:50:17 UTC 2008
Responsible-Changed-Why:
Over to maintainer (via the GNATS Auto Assign Tool)
http://www.freebsd.org/cgi/query-pr.cgi?pr=128998
From rea-fbsd at codelabs.ru Wed Nov 19 13:30:14 2008
From: rea-fbsd at codelabs.ru (Eygene Ryabinkin)
Date: Wed Nov 19 13:30:27 2008
Subject: ports/128999: [vuxml] [patch] update audio/streamripper to 1.64.0,
fix CVE-2008-4829
Message-ID: <20081119212940.A0D98F181F@phoenix.codelabs.ru>
>Number: 128999
>Category: ports
>Synopsis: [vuxml] [patch] update audio/streamripper to 1.64.0, fix CVE-2008-4829
>Confidential: no
>Severity: serious
>Priority: high
>Responsible: freebsd-ports-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Wed Nov 19 21:30:14 UTC 2008
>Closed-Date:
>Last-Modified:
>Originator: Eygene Ryabinkin
>Release: FreeBSD 7.1-PRERELEASE i386
>Organization:
Code Labs
>Environment:
System: FreeBSD 7.1-PRERELEASE i386
>Description:
Streamripper 1.64.0 is out and this release fixes security vulnerability
discovered by Secunia.
>How-To-Repeat:
http://streamripper.cvs.sourceforge.net/viewvc/streamripper/sripper_1x/CHANGES?revision=1.196
http://secunia.com/secunia_research/2008-50/
>Fix:
The following patch updates the port to 1.64.0. It works for me: MP3
streams are ripped perfectly.
--- 1.63.5-to-1.64.0-fix-cve-2008-4829.diff begins here ---
diff -urN ./Makefile ../streamripper/Makefile
--- ./Makefile 2008-11-19 23:50:33.000000000 +0300
+++ ../streamripper/Makefile 2008-11-19 23:57:00.000000000 +0300
@@ -6,7 +6,7 @@
#
PORTNAME= streamripper
-PORTVERSION= 1.63.5
+PORTVERSION= 1.64.0
CATEGORIES= audio
MASTER_SITES= SF \
http://gd.tuwien.ac.at/hci/cdk/:cdk
diff -urN ./distinfo ../streamripper/distinfo
--- ./distinfo 2008-11-19 23:50:33.000000000 +0300
+++ ../streamripper/distinfo 2008-11-19 23:57:19.000000000 +0300
@@ -1,6 +1,6 @@
-MD5 (streamripper-1.63.5.tar.gz) = 73a63383dca00615c3328cf51bf2fa56
-SHA256 (streamripper-1.63.5.tar.gz) = 877aed28880b904383c4e761c0ecb1e046dbe45126e648110c0292991d1e5b93
-SIZE (streamripper-1.63.5.tar.gz) = 1302177
+MD5 (streamripper-1.64.0.tar.gz) = f8754813ddc2bc96c4c3440e25aca8b6
+SHA256 (streamripper-1.64.0.tar.gz) = a53f50d26de3610e59a07eaf81cc9da348aaf7b35bc4a302f2e5f6defb1297ae
+SIZE (streamripper-1.64.0.tar.gz) = 839535
MD5 (cdk-5.0-20060507.tgz) = 0ec2460a4484d5f5595d8faca61bc9c5
SHA256 (cdk-5.0-20060507.tgz) = e823bfcce52916727cb23d6d549a64347c45c364b3c628d6a352c407fce8f4b4
SIZE (cdk-5.0-20060507.tgz) = 396514
--- 1.63.5-to-1.64.0-fix-cve-2008-4829.diff ends here ---
The following VuXML entry should be evaluated and added:
--- vuln.xml begins here ---
streamripper -- user-assisted arbitrary code execution
streamripper
1.64.0
Secunia Research has discovered some vulnerabilities in
Streamripper, which can be exploited by malicious people to
compromise a user's system:
- A boundary error exists within http_parse_sc_header() in
lib/http.c when parsing an overly long HTTP header starting
with “Zwitterion v”.
- A boundary error exists within http_get_pls() in
lib/http.c when parsing a specially crafted pls playlist
containing an overly long entry.
- A boundary error exists within http_get_m3u() in
lib/http.c when parsing a specially crafted m3u playlist
containing an overly long “File” entry.
Successful exploitation allows execution of arbitrary
code, but requires that a user is tricked into connecting
to a malicious server.
CVE-2008-4829
http://secunia.com/secunia_research/2008-50/
http://streamripper.cvs.sourceforge.net/viewvc/streamripper/sripper_1x/CHANGES?revision=1.196
2008-11-19
--- vuln.xml ends here ---
>Release-Note:
>Audit-Trail:
>Unformatted:
From rea-fbsd at codelabs.ru Wed Nov 19 14:00:12 2008
From: rea-fbsd at codelabs.ru (Eygene Ryabinkin)
Date: Wed Nov 19 14:00:19 2008
Subject: ports/129000: [vuxml] mail/dovecot: document CVE-2008-4577 and
CVE-2008-4578
Message-ID: <20081119215959.9FC17F181F@phoenix.codelabs.ru>
>Number: 129000
>Category: ports
>Synopsis: [vuxml] mail/dovecot: document CVE-2008-4577 and CVE-2008-4578
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: freebsd-ports-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Wed Nov 19 22:00:10 UTC 2008
>Closed-Date:
>Last-Modified:
>Originator: Eygene Ryabinkin
>Release: FreeBSD 7.1-PRERELEASE i386
>Organization:
Code Labs
>Environment:
System: FreeBSD 7.1-PRERELEASE i386
>Description:
There were two vulnerabilities in the ACL handling for Dovecot prior
to the 1.1.4 [1]:
-----
- ACL plugin fixes: Negative rights were actually treated as positive
rights. 'k' right didn't prevent creating parent/child/child mailbox.
ACL groups weren't working.
-----
[1] http://www.dovecot.org/list/dovecot-news/2008-October/000085.html
>How-To-Repeat:
http://www.dovecot.org/list/dovecot-news/2008-October/000085.html
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4577
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4578
>Fix:
The following VuXML entry should be evaluated and added:
--- vuln.xml begins here ---
dovecot -- two ACL bypassing vulnerabilities
dovecot
1.1.6
Dovecot 1.1.4 release announcement says:
ACL plugin fixes: Negative rights were actually treated as
positive rights. 'k' right didn't prevent creating
parent/child/child mailbox. ACL groups weren't working.
CVE-2008-4577
http://www.dovecot.org/list/dovecot-news/2008-October/000085.html
2008-10-05
--- vuln.xml ends here ---
I am putting '< 1.1.6' because FreeBSD ports version line was the
following: ... -> 1.1.3 -> 1.1.6.
>Release-Note:
>Audit-Trail:
>Unformatted:
From rea-fbsd at codelabs.ru Wed Nov 19 14:04:35 2008
From: rea-fbsd at codelabs.ru (Eygene Ryabinkin)
Date: Wed Nov 19 14:04:42 2008
Subject: ports/128998: [vuxml] document vulnerabilities in
textproc/libxml2
In-Reply-To: <20081119204101.5FBD7F181F@phoenix.codelabs.ru>
References: <20081119204101.5FBD7F181F@phoenix.codelabs.ru>
Message-ID:
Wed, Nov 19, 2008 at 11:41:01PM +0300, Eygene Ryabinkin wrote:
> The fix for the CVE-2008-4225 and CVE-2008-4226 was commited to the
> textproc/libxml2 just an hour ago, but vulnerabilities seem to be left
> undocumented. At least I was not able to find the corresponding PR and
> reporting channels are not clear from the commit comment.
The entry was added shortly after this PR by tabthorpe@, so I think
that this PR can be closed now.
--
Eygene
_ ___ _.--. #
\`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, / # while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / # -- FreeBSD Developers handbook
{_.-``-' {_/ #
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-security/attachments/20081119/742fa030/attachment.pgp
From pluknet at gmail.com Wed Nov 19 13:57:32 2008
From: pluknet at gmail.com (pluknet)
Date: Wed Nov 19 15:15:42 2008
Subject: ports/128998: [vuxml] document vulnerabilities in
textproc/libxml2
In-Reply-To: <200811192050.mAJKoHo1057543@freefall.freebsd.org>
References: <200811192050.mAJKoHo1057543@freefall.freebsd.org>
Message-ID:
2008/11/19 :
> Synopsis: [vuxml] document vulnerabilities in textproc/libxml2
>
> Responsible-Changed-From-To: freebsd-ports-bugs->gnome
> Responsible-Changed-By: edwin
> Responsible-Changed-When: Wed Nov 19 20:50:17 UTC 2008
> Responsible-Changed-Why:
> Over to maintainer (via the GNATS Auto Assign Tool)
>
> http://www.freebsd.org/cgi/query-pr.cgi?pr=128998
>
Committed as r1.1758 and it can be closed.
From edwin at FreeBSD.org Wed Nov 19 14:00:28 2008
From: edwin at FreeBSD.org (edwin@FreeBSD.org)
Date: Wed Nov 19 15:15:50 2008
Subject: ports/129000: [vuxml] mail/dovecot: document CVE-2008-4577 and
CVE-2008-4578
Message-ID: <200811192200.mAJM0SUi009520@freefall.freebsd.org>
Synopsis: [vuxml] mail/dovecot: document CVE-2008-4577 and CVE-2008-4578
State-Changed-From-To: open->feedback
State-Changed-By: edwin
State-Changed-When: Wed Nov 19 22:00:27 UTC 2008
State-Changed-Why:
Awaiting maintainers feedback (via the GNATS Auto Assign Tool)
http://www.freebsd.org/cgi/query-pr.cgi?pr=129000
From rea-fbsd at codelabs.ru Wed Nov 19 15:16:11 2008
From: rea-fbsd at codelabs.ru (Eygene Ryabinkin)
Date: Wed Nov 19 15:16:18 2008
Subject: ports/129000: [vuxml] mail/dovecot: document CVE-2008-4577 and
CVE-2008-4578
In-Reply-To: <200811192237.mAJMbCnZ038587@freefall.freebsd.org>
References: <200811192237.mAJMbCnZ038587@freefall.freebsd.org>
Message-ID:
Xin, good day.
Wed, Nov 19, 2008 at 10:37:12PM +0000, delphij@FreeBSD.org wrote:
> Synopsis: [vuxml] mail/dovecot: document CVE-2008-4577 and CVE-2008-4578
>
> State-Changed-From-To: open->closed
> State-Changed-By: delphij
> State-Changed-When: Wed Nov 19 22:36:55 UTC 2008
> State-Changed-Why:
> Committed with some changes, thanks!
Thanks for handling this. But I have a question: what is the general
policy about versions that are to be documented within the 'range'
clauses? You had changed version specification to '1.1.4', but it was
never been in the FreeBSD ports tree. So, should we specify only
existing port versions or we can specify vendor-specific versions as
well, provided that the specification will be the same from the point of
view of the port version evolution?
Thanks again!
--
Eygene
_ ___ _.--. #
\`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, / # while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / # -- FreeBSD Developers handbook
{_.-``-' {_/ #
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-security/attachments/20081119/4989b057/attachment.pgp
From linimon at FreeBSD.org Wed Nov 19 14:07:38 2008
From: linimon at FreeBSD.org (linimon@FreeBSD.org)
Date: Wed Nov 19 15:42:47 2008
Subject: ports/128998: [vuxml] document vulnerabilities in
textproc/libxml2
Message-ID: <200811192207.mAJM7bqt014472@freefall.freebsd.org>
Synopsis: [vuxml] document vulnerabilities in textproc/libxml2
State-Changed-From-To: open->closed
State-Changed-By: linimon
State-Changed-When: Wed Nov 19 22:07:06 UTC 2008
State-Changed-Why:
Already committed.
http://www.freebsd.org/cgi/query-pr.cgi?pr=128998
From delphij at delphij.net Wed Nov 19 15:46:20 2008
From: delphij at delphij.net (Xin LI)
Date: Wed Nov 19 15:49:54 2008
Subject: ports/129000: [vuxml] mail/dovecot: document CVE-2008-4577 and
CVE-2008-4578
In-Reply-To:
References: <200811192237.mAJMbCnZ038587@freefall.freebsd.org>
Message-ID: <4924A53F.10400@delphij.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Eygene Ryabinkin wrote:
> Xin, good day.
>
> Wed, Nov 19, 2008 at 10:37:12PM +0000, delphij@FreeBSD.org wrote:
>> Synopsis: [vuxml] mail/dovecot: document CVE-2008-4577 and CVE-2008-4578
>>
>> State-Changed-From-To: open->closed
>> State-Changed-By: delphij
>> State-Changed-When: Wed Nov 19 22:36:55 UTC 2008
>> State-Changed-Why:
>> Committed with some changes, thanks!
>
> Thanks for handling this. But I have a question: what is the general
> policy about versions that are to be documented within the 'range'
> clauses? You had changed version specification to '1.1.4', but it was
> never been in the FreeBSD ports tree. So, should we specify only
> existing port versions or we can specify vendor-specific versions as
> well, provided that the specification will be the same from the point of
> view of the port version evolution?
The '1.1.4' was chosen because that the official release notes said so,
and it is the exact minimum version of the port, if it ever got into the
tree. Personally I think it's a bad idea to cover versions that we are
known not to be vulnerable, for instance, the user might be running
1.1.4 or 1.1.5 with their local patched versions and does not want to
upgrade, making false positives would actually hurt the credibility of
vuxml.
Cheers,
- --
Xin LI http://www.delphij.net/
FreeBSD - The Power to Serve!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (FreeBSD)
iEYEARECAAYFAkkkpT8ACgkQi+vbBBjt66BfdQCgvaViet3vX/oDTITgj0nP099r
yyIAn05iXdtYM0uU5oNBWBXcHEcHFFiF
=T4Wi
-----END PGP SIGNATURE-----
From rea-fbsd at codelabs.ru Wed Nov 19 16:40:02 2008
From: rea-fbsd at codelabs.ru (Eygene Ryabinkin)
Date: Wed Nov 19 16:40:09 2008
Subject: ports/129001: [vuxml] [patch] print/cups-base: fix NULL-pointer
dereference
Message-ID: <20081120003600.6DB2F1AF41B@void.codelabs.ru>
>Number: 129001
>Category: ports
>Synopsis: [vuxml] [patch] print/cups-base: fix NULL-pointer dereference
>Confidential: no
>Severity: serious
>Priority: high
>Responsible: freebsd-ports-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Thu Nov 20 00:40:01 UTC 2008
>Closed-Date:
>Last-Modified:
>Originator: Eygene Ryabinkin
>Release: FreeBSD 7.1-PRERELEASE i386
>Organization:
Code Labs
>Environment:
System: FreeBSD 7.1-PRERELEASE i386
>Description:
It was discovered [1] that CUPS up to 1.3.9 has code path that will
dereference NULL pointer and it is trivially reproducible when user hits
the subscription limit, for example via repeated commands 'lpr -m
'.
[1] http://www.openwall.com/lists/oss-security/2008/11/19/4/ and
the rest of the thread.
>How-To-Repeat:
Set 'MaxSubscriptions' in the cupsd.conf to some small value and invoke
'lpr -m ' multiple times. You'll see that after some attempt
server will be unreachable due to its crash. Default value of 100 for
MaxSubscription does not prevent the DoS, because many big files could
be feeded to CUPS daemon.
>Fix:
There is no official fix yet -- I had just informed CUPS developer and
posted the simple patch to the oss-security mailing list. Here is the
patch that will introduce checks for the values returned by
cupsdAddSubscription() and bump port version:
--- 1.3.9-to-1.3.9_1-fix-null-deference.patch begins here ---
diff -urN ./Makefile ../cups-base/Makefile
--- ./Makefile 2008-11-20 02:48:10.000000000 +0300
+++ ../cups-base/Makefile 2008-11-20 03:07:03.000000000 +0300
@@ -7,6 +7,7 @@
PORTNAME= cups
PORTVERSION= 1.3.9
+PORTREVISION= 1
DISTVERSIONSUFFIX= -source
CATEGORIES= print
MASTER_SITES= EASYSW/${PORTNAME}/${DISTVERSION}
diff -urN ./files/patch-fix-subscriptions-null-dereference ../cups-base/files/patch-fix-subscriptions-null-dereference
--- ./files/patch-fix-subscriptions-null-dereference 1970-01-01 03:00:00.000000000 +0300
+++ ../cups-base/files/patch-fix-subscriptions-null-dereference 2008-11-20 03:11:26.000000000 +0300
@@ -0,0 +1,48 @@
+--- scheduler/subscriptions.c.orig 2008-11-20 02:57:17.000000000 +0300
++++ scheduler/subscriptions.c 2008-11-20 03:02:06.000000000 +0300
+@@ -728,6 +728,13 @@
+ {
+ sub = cupsdAddSubscription(CUPSD_EVENT_NONE, NULL, NULL, NULL,
+ atoi(value));
++ if (!sub)
++ {
++ cupsdLogMessage(CUPSD_LOG_ERROR,
++ "Unable to add new subscription. Was parsing line %d of subscriptions.conf.",
++ linenum);
++ break;
++ }
+ }
+ else
+ {
+--- scheduler/ipp.c.orig 2008-11-20 02:55:59.000000000 +0300
++++ scheduler/ipp.c 2008-11-20 02:56:03.000000000 +0300
+@@ -2121,6 +2121,14 @@
+
+ sub = cupsdAddSubscription(mask, cupsdFindDest(job->dest), job, recipient,
+ 0);
++ if (!sub)
++ {
++ cupsdLogMessage(CUPSD_LOG_ERROR,
++ "Failed to create subscription for job %d", job->id);
++ send_ipp_status(con, IPP_TOO_MANY_SUBSCRIPTIONS,
++ _("Unable to add new subscription"));
++ return;
++ }
+
+ sub->interval = interval;
+
+@@ -5591,6 +5599,14 @@
+ job = NULL;
+
+ sub = cupsdAddSubscription(mask, printer, job, recipient, 0);
++ if (!sub)
++ {
++ cupsdLogMessage(CUPSD_LOG_ERROR,
++ "Failed to create subscription for job %d", job->id);
++ send_ipp_status(con, IPP_TOO_MANY_SUBSCRIPTIONS,
++ _("Unable to add new subscription"));
++ return;
++ }
+
+ if (job)
+ cupsdLogMessage(CUPSD_LOG_DEBUG, "Added subscription %d for job %d",
--- 1.3.9-to-1.3.9_1-fix-null-deference.patch ends here ---
The preliminary VuXML entry follows:
--- vuln.xml begins here ---
cups -- Denial of Service by authenticated client
cups-base
1.3.9_1
Josh Bressers discovered that CUPS daemon can be crashed
via trivial NULL-pointer dereference:
The upstream fix could still obviously let a local
authenticated user crash the server.
http://www.openwall.com/lists/oss-security/2008/11/19/4/
2008-11-19
--- vuln.xml ends here ---
Please, note that this vulnerability was already disclosed in the
oss-security mailing list, so there is no much sense in hiding this
discussion.
>Release-Note:
>Audit-Trail:
>Unformatted:
From rea-fbsd at codelabs.ru Wed Nov 19 16:44:05 2008
From: rea-fbsd at codelabs.ru (Eygene Ryabinkin)
Date: Wed Nov 19 16:44:12 2008
Subject: ports/129000: [vuxml] mail/dovecot: document CVE-2008-4577 and
CVE-2008-4578
In-Reply-To: <4924A53F.10400@delphij.net>
References: <200811192237.mAJMbCnZ038587@freefall.freebsd.org>
<4924A53F.10400@delphij.net>
Message-ID:
Xin,
Wed, Nov 19, 2008 at 03:46:07PM -0800, Xin LI wrote:
> > Thanks for handling this. But I have a question: what is the general
> > policy about versions that are to be documented within the 'range'
> > clauses? You had changed version specification to '1.1.4', but it was
> > never been in the FreeBSD ports tree. So, should we specify only
> > existing port versions or we can specify vendor-specific versions as
> > well, provided that the specification will be the same from the point of
> > view of the port version evolution?
>
> The '1.1.4' was chosen because that the official release notes said so,
> and it is the exact minimum version of the port, if it ever got into the
> tree. Personally I think it's a bad idea to cover versions that we are
> known not to be vulnerable, for instance, the user might be running
> 1.1.4 or 1.1.5 with their local patched versions and does not want to
> upgrade, making false positives would actually hurt the credibility of
> vuxml.
OK, I expected such answer. But then, what you'll say after reading
the history of ports/128698:
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/128698
I understand that the mentioned PR is the another case and there were no
vulnerable version in the official ports tree. But two PRs are a bit
inconsistent in their treatment of the locally patched versions, so I am
just curious -- may be there should be some general understanding about
this?
Sorry for being so chatty, but I am just trying to understand the policy
and best practices for VuXML.
Thanks!
--
Eygene
_ ___ _.--. #
\`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, / # while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / # -- FreeBSD Developers handbook
{_.-``-' {_/ #
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-security/attachments/20081120/5b6accce/attachment.pgp
From edwin at FreeBSD.org Wed Nov 19 16:40:18 2008
From: edwin at FreeBSD.org (edwin@FreeBSD.org)
Date: Wed Nov 19 16:59:37 2008
Subject: ports/129001: [vuxml] [patch] print/cups-base: fix NULL-pointer
dereference
Message-ID: <200811200040.mAK0eHxN032089@freefall.freebsd.org>
Synopsis: [vuxml] [patch] print/cups-base: fix NULL-pointer dereference
Responsible-Changed-From-To: freebsd-ports-bugs->dinoex
Responsible-Changed-By: edwin
Responsible-Changed-When: Thu Nov 20 00:40:17 UTC 2008
Responsible-Changed-Why:
Over to maintainer (via the GNATS Auto Assign Tool)
http://www.freebsd.org/cgi/query-pr.cgi?pr=129001
From miwi at FreeBSD.org Wed Nov 19 21:31:50 2008
From: miwi at FreeBSD.org (miwi@FreeBSD.org)
Date: Wed Nov 19 21:32:07 2008
Subject: ports/128999: [vuxml] [patch] update audio/streamripper to
1.64.0, fix CVE-2008-4829
Message-ID: <200811200531.mAK5VoML059609@freefall.freebsd.org>
Synopsis: [vuxml] [patch] update audio/streamripper to 1.64.0, fix CVE-2008-4829
Responsible-Changed-From-To: freebsd-ports-bugs->miwi
Responsible-Changed-By: miwi
Responsible-Changed-When: Thu Nov 20 05:31:49 UTC 2008
Responsible-Changed-Why:
I'll take it.
http://www.freebsd.org/cgi/query-pr.cgi?pr=128999
From rea-fbsd at codelabs.ru Thu Nov 20 00:58:29 2008
From: rea-fbsd at codelabs.ru (Eygene Ryabinkin)
Date: Thu Nov 20 00:58:35 2008
Subject: ports/129001: [vuxml] [patch] print/cups-base: fix
NULL-pointer dereference
In-Reply-To: <20081120003600.6DB2F1AF41B@void.codelabs.ru>
References: <20081120003600.6DB2F1AF41B@void.codelabs.ru>
Message-ID:
Me again.
Thu, Nov 20, 2008 at 03:36:00AM +0300, Eygene Ryabinkin wrote:
> It was discovered [1] that CUPS up to 1.3.9 has code path that will
> dereference NULL pointer and it is trivially reproducible when user hits
> the subscription limit, for example via repeated commands 'lpr -m
> '.
>
> [1] http://www.openwall.com/lists/oss-security/2008/11/19/4/ and
> the rest of the thread.
Michael Sweet provided more complete patch [2] that is already in the
1.3.x Subversion repository.
[2] http://www.openwall.com/lists/oss-security/2008/11/20/2
Had tested the patch -- it works too.
Attaching modified port patch and reworked VuXML entry.
--- 1.3.9-to-1.3.9_1-fix-null-deference-upstream.patch begins here ---
diff -urN ./Makefile ../cups-base/Makefile
--- ./Makefile 2008-11-20 02:48:10.000000000 +0300
+++ ../cups-base/Makefile 2008-11-20 03:07:03.000000000 +0300
@@ -7,6 +7,7 @@
PORTNAME= cups
PORTVERSION= 1.3.9
+PORTREVISION= 1
DISTVERSIONSUFFIX= -source
CATEGORIES= print
MASTER_SITES= EASYSW/${PORTNAME}/${DISTVERSION}
diff -urN ./files/patch-fix-subscriptions-null-dereference ../cups-base/files/patch-fix-subscriptions-null-dereference
--- ./files/patch-fix-subscriptions-null-dereference 1970-01-01 03:00:00.000000000 +0300
+++ ../cups-base/files/patch-fix-subscriptions-null-dereference 2008-11-20 11:33:59.000000000 +0300
@@ -0,0 +1,179 @@
+Obtained from: Michael Sweet, via oss-security list,
+ http://www.openwall.com/lists/oss-security/2008/11/20/2
+
+Index: test/run-stp-tests.sh
+===================================================================
+--- test/run-stp-tests.sh (revision 8145)
++++ test/run-stp-tests.sh (revision 8146)
+@@ -307,6 +307,7 @@
+ DocumentRoot $root/doc
+ RequestRoot /tmp/cups-$user/spool
+ TempDir /tmp/cups-$user/spool/temp
++MaxSubscriptions 3
+ MaxLogSize 0
+ AccessLog /tmp/cups-$user/log/access_log
+ ErrorLog /tmp/cups-$user/log/error_log
+Index: test/4.4-subscription-ops.test
+===================================================================
+--- test/4.4-subscription-ops.test (revision 8145)
++++ test/4.4-subscription-ops.test (revision 8146)
+@@ -116,7 +116,33 @@
+ EXPECT notify-events
+ DISPLAY notify-events
+ }
++{
++ # The name of the test...
++ NAME "Check MaxSubscriptions limits"
+
++ # The operation to use
++ OPERATION Create-Printer-Subscription
++ RESOURCE /
++
++ # The attributes to send
++ GROUP operation
++ ATTR charset attributes-charset utf-8
++ ATTR language attributes-natural-language en
++ ATTR uri printer-uri $method://$hostname:$port/printers/Test1
++
++ GROUP subscription
++ ATTR uri notify-recipient-uri testnotify://
++ ATTR keyword notify-events printer-state-changed
++ ATTR integer notify-lease-duration 5
++
++ # What statuses are OK?
++ STATUS client-error-too-many-subscriptions
++
++ # What attributes do we expect?
++ EXPECT attributes-charset
++ EXPECT attributes-natural-language
++}
++
+ #
+ # End of "$Id$"
+ #
+Index: scheduler/subscriptions.c
+===================================================================
+--- scheduler/subscriptions.c (revision 8145)
++++ scheduler/subscriptions.c (revision 8146)
+@@ -341,9 +341,55 @@
+ * Limit the number of subscriptions...
+ */
+
+- if (cupsArrayCount(Subscriptions) >= MaxSubscriptions)
++ if (MaxSubscriptions > 0 && cupsArrayCount(Subscriptions) >= MaxSubscriptions)
++ {
++ cupsdLogMessage(CUPSD_LOG_DEBUG,
++ "cupsdAddSubscription: Reached MaxSubscriptions %d",
++ MaxSubscriptions);
+ return (NULL);
++ }
+
++ if (MaxSubscriptionsPerJob > 0 && job)
++ {
++ int count; /* Number of job subscriptions */
++
++ for (temp = (cupsd_subscription_t *)cupsArrayFirst(Subscriptions),
++ count = 0;
++ temp;
++ temp = (cupsd_subscription_t *)cupsArrayNext(Subscriptions))
++ if (temp->job == job)
++ count ++;
++
++ if (count >= MaxSubscriptionsPerJob)
++ {
++ cupsdLogMessage(CUPSD_LOG_DEBUG,
++ "cupsdAddSubscription: Reached MaxSubscriptionsPerJob %d "
++ "for job #%d", MaxSubscriptionsPerJob, job->id);
++ return (NULL);
++ }
++ }
++
++ if (MaxSubscriptionsPerPrinter > 0 && dest)
++ {
++ int count; /* Number of printer subscriptions */
++
++ for (temp = (cupsd_subscription_t *)cupsArrayFirst(Subscriptions),
++ count = 0;
++ temp;
++ temp = (cupsd_subscription_t *)cupsArrayNext(Subscriptions))
++ if (temp->dest == dest)
++ count ++;
++
++ if (count >= MaxSubscriptionsPerPrinter)
++ {
++ cupsdLogMessage(CUPSD_LOG_DEBUG,
++ "cupsdAddSubscription: Reached "
++ "MaxSubscriptionsPerPrinter %d for %s",
++ MaxSubscriptionsPerPrinter, dest->name);
++ return (NULL);
++ }
++ }
++
+ /*
+ * Allocate memory for this subscription...
+ */
+@@ -758,7 +804,6 @@
+ cupsdLogMessage(CUPSD_LOG_ERROR,
+ "Syntax error on line %d of subscriptions.conf.",
+ linenum);
+- break;
+ }
+ else if (!strcasecmp(line, "Events"))
+ {
+Index: scheduler/ipp.c
+===================================================================
+--- scheduler/ipp.c (revision 8145)
++++ scheduler/ipp.c (revision 8146)
+@@ -2119,24 +2119,25 @@
+ if (mask == CUPSD_EVENT_NONE)
+ mask = CUPSD_EVENT_JOB_COMPLETED;
+
+- sub = cupsdAddSubscription(mask, cupsdFindDest(job->dest), job, recipient,
+- 0);
++ if ((sub = cupsdAddSubscription(mask, cupsdFindDest(job->dest), job,
++ recipient, 0)) != NULL)
++ {
++ sub->interval = interval;
+
+- sub->interval = interval;
++ cupsdSetString(&sub->owner, job->username);
+
+- cupsdSetString(&sub->owner, job->username);
++ if (user_data)
++ {
++ sub->user_data_len = user_data->values[0].unknown.length;
++ memcpy(sub->user_data, user_data->values[0].unknown.data,
++ sub->user_data_len);
++ }
+
+- if (user_data)
+- {
+- sub->user_data_len = user_data->values[0].unknown.length;
+- memcpy(sub->user_data, user_data->values[0].unknown.data,
+- sub->user_data_len);
++ ippAddSeparator(con->response);
++ ippAddInteger(con->response, IPP_TAG_SUBSCRIPTION, IPP_TAG_INTEGER,
++ "notify-subscription-id", sub->id);
+ }
+
+- ippAddSeparator(con->response);
+- ippAddInteger(con->response, IPP_TAG_SUBSCRIPTION, IPP_TAG_INTEGER,
+- "notify-subscription-id", sub->id);
+-
+ if (attr)
+ attr = attr->next;
+ }
+@@ -5590,7 +5591,12 @@
+ else
+ job = NULL;
+
+- sub = cupsdAddSubscription(mask, printer, job, recipient, 0);
++ if ((sub = cupsdAddSubscription(mask, printer, job, recipient, 0)) == NULL)
++ {
++ send_ipp_status(con, IPP_TOO_MANY_SUBSCRIPTIONS,
++ _("There are too many subscriptions."));
++ return;
++ }
+
+ if (job)
+ cupsdLogMessage(CUPSD_LOG_DEBUG, "Added subscription %d for job %d",
--- 1.3.9-to-1.3.9_1-fix-null-deference-upstream.patch ends here ---
--- vuln.xml begins here ---
cups scheduler -- Denial of Service by authorized client
cups-base
1.3.9_1
ChangeLog for CUPS 1.3.10 says:
The scheduler would crash if you exceeded the
MaxSubscriptions limit.
http://svn.easysw.com/public/cups/trunk/CHANGES-1.3.txt
http://www.openwall.com/lists/oss-security/2008/11/19/4/
2008-11-19
--- vuln.xml ends here ---
--
Eygene
_ ___ _.--. #
\`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, / # while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / # -- FreeBSD Developers handbook
{_.-``-' {_/ #
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-security/attachments/20081120/86095d4f/attachment.pgp
From delphij at delphij.net Thu Nov 20 12:01:32 2008
From: delphij at delphij.net (Xin LI)
Date: Thu Nov 20 12:01:39 2008
Subject: ports/129000: [vuxml] mail/dovecot: document CVE-2008-4577 and
CVE-2008-4578
In-Reply-To:
References: <200811192237.mAJMbCnZ038587@freefall.freebsd.org>
<4924A53F.10400@delphij.net>
Message-ID: <4925C20C.5020107@delphij.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi, Eygene,
Eygene Ryabinkin wrote:
> Xin,
>
> Wed, Nov 19, 2008 at 03:46:07PM -0800, Xin LI wrote:
>>> Thanks for handling this. But I have a question: what is the general
>>> policy about versions that are to be documented within the 'range'
>>> clauses? You had changed version specification to '1.1.4', but it was
>>> never been in the FreeBSD ports tree. So, should we specify only
>>> existing port versions or we can specify vendor-specific versions as
>>> well, provided that the specification will be the same from the point of
>>> view of the port version evolution?
>> The '1.1.4' was chosen because that the official release notes said so,
>> and it is the exact minimum version of the port, if it ever got into the
>> tree. Personally I think it's a bad idea to cover versions that we are
>> known not to be vulnerable, for instance, the user might be running
>> 1.1.4 or 1.1.5 with their local patched versions and does not want to
>> upgrade, making false positives would actually hurt the credibility of
>> vuxml.
>
> OK, I expected such answer. But then, what you'll say after reading
> the history of ports/128698:
> http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/128698
>
> I understand that the mentioned PR is the another case and there were no
> vulnerable version in the official ports tree. But two PRs are a bit
> inconsistent in their treatment of the locally patched versions, so I am
> just curious -- may be there should be some general understanding about
> this?
>
> Sorry for being so chatty, but I am just trying to understand the policy
> and best practices for VuXML.
Ok I understood what you mean. I have cc'ed miwi@ and stas@, it looks
like that the PR 128698 should be committed and not be closed from my
understanding, but that's my personal opinion.
In my opinion, there is nothing wrong to inform our user community about
a problem that may affect FreeBSD with the third party software. The
concept of "we protect users who use official FreeBSD tree" is good, but
the long freeze/slush time could cause users to derive their own
variants to the tree, maybe by applying the patches in PR (that is
usually seen in replies to -ports@) themselves. Moreover, I think it's
wrong to close ticket 128698 if no update to 1.1.6 has been committed,
because committer is a large team and this one should have followed the
better safe than sorry rule.
Now that the mail/dovecot has been updated to 1.1.6 and it's true that
1.1.5 and 1.1.4 (affected by 128698) never hit the tree. Because
CVE-2008-4577 and CVE-2008-4578 affects only < 1.1.4 versions, it's
wrong to document it as < 1.1.6. However, if the entry has been amended
to cover CVE-2008-4907 as a multiple vulnerabilities issue for dovecot
then I don't think covering < 1.1.6 would be a wrong thing to do.
Cheers,
- --
Xin LI http://www.delphij.net/
FreeBSD - The Power to Serve!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (FreeBSD)
iEYEARECAAYFAkklwf0ACgkQi+vbBBjt66Cf5ACeKxd7Kb8nwctJ5lVA2JoMUXH7
BRsAoLMZ56EQCpZ77u0cbbwVXu5u1NMa
=PnV2
-----END PGP SIGNATURE-----
From coley at linus.mitre.org Thu Nov 20 16:04:28 2008
From: coley at linus.mitre.org (Steven M. Christey)
Date: Thu Nov 20 16:09:05 2008
Subject: ports/128956: [patch] [vuxml] multiple vulnerabilities in PHP
5.2.6
In-Reply-To:
References: <20081118103433.38D5817115@shadow.codelabs.ru>
<4922B371.6070002@quis.cx>
<4922B6F9.2000408@quis.cx>
<9a6isDG2HABVFiTQKRYgHLbugj0@N7cbPDipnvOyJMD9YzFbYf8QNqE>
Message-ID:
Thank you for answering, Eygene.
- Steve
From rea-fbsd at codelabs.ru Thu Nov 20 21:50:02 2008
From: rea-fbsd at codelabs.ru (Eygene Ryabinkin)
Date: Thu Nov 20 21:50:09 2008
Subject: ports/129037: [patch] [vuxml] graphics/imlib2: fix CVE-2008-5187
Message-ID: <20081121054124.C219F1AF41B@void.codelabs.ru>
>Number: 129037
>Category: ports
>Synopsis: [patch] [vuxml] graphics/imlib2: fix CVE-2008-5187
>Confidential: no
>Severity: critical
>Priority: high
>Responsible: freebsd-ports-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Fri Nov 21 05:50:01 UTC 2008
>Closed-Date:
>Last-Modified:
>Originator: Eygene Ryabinkin
>Release: FreeBSD 7.1-PRERELEASE i386
>Organization:
Code Labs
>Environment:
System: FreeBSD 7.1-PRERELEASE i386
>Description:
Secunia discovered imlib2 vulnerability that can be used to execute
arbitrary code within the application that uses this library:
-----
The vulnerability is caused due to a pointer arithmetic error within the
"load()" function provided by the XPM loader. This can be exploited to
cause a heap-based buffer overflow via a specially crafted XPM file.
Successful exploitation may allow execution of arbitrary code.
-----
>How-To-Repeat:
http://secunia.com/Advisories/32796
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5187
>Fix:
The following patch adds the patch from Debian developers. It is supposed
to fix the issue.
--- fix-imlib2-1.4.1.000.diff begins here ---
diff -urN ./Makefile ../imlib2/Makefile
--- ./Makefile 2008-11-20 20:30:31.000000000 +0300
+++ ../imlib2/Makefile 2008-11-21 08:28:40.000000000 +0300
@@ -7,7 +7,7 @@
PORTNAME= imlib2
PORTVERSION= 1.4.1.000
-PORTREVISION= 0
+PORTREVISION= 1
PORTEPOCH= 2
CATEGORIES= graphics
MASTER_SITES= ftp://ftp.springdaemons.com/pub/snapshots/e17/ \
diff -urN ./files/patch-CVE-2008-5187 ../imlib2/files/patch-CVE-2008-5187
--- ./files/patch-CVE-2008-5187 1970-01-01 03:00:00.000000000 +0300
+++ ../imlib2/files/patch-CVE-2008-5187 2008-11-21 08:24:16.000000000 +0300
@@ -0,0 +1,14 @@
+Obtained from: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=505714#15
+
+--- src/modules/loaders/loader_xpm.c
++++ src/modules/loaders/loader_xpm.c
+@@ -246,8 +246,8 @@
+ return 0;
+ }
+ ptr = im->data;
+- end = ptr + (sizeof(DATA32) * w * h);
+ pixels = w * h;
++ end = ptr + pixels;
+ }
+ else
+ {
--- fix-imlib2-1.4.1.000.diff ends here ---
The following VuXML entry should be validated and added:
--- vuln.xml begins here ---
imlib2 -- XPM processing buffer overflow vulnerability
imlib2
imlib2-nox11
1.4.1.000_1,2
Secunia reports:
A vulnerability has been discovered in imlib2, which can
be exploited by malicious people to potentially compromise
an application using the library.
The vulnerability is caused due to a pointer arithmetic
error within the "load()" function provided by the XPM
loader. This can be exploited to cause a heap-based buffer
overflow via a specially crafted XPM file.
Successful exploitation may allow execution of arbitrary
code.
The vulnerability is confirmed in version 1.4.2. Other
versions may also be affected.
CVE-2008-5187
http://secunia.com/Advisories/32796
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=505714#15
http://bugzilla.enlightenment.org/show_bug.cgi?id=547
2008-11-20
--- vuln.xml ends here ---
I see that XPM loader is built and installed even for the nox11 version,
so I am including it to the vulnerable port. imlib-1.9.15 seem to be
unaffected: it has the code in question, but it does memory manipulations
properly.
>Release-Note:
>Audit-Trail:
>Unformatted:
From rea-fbsd at codelabs.ru Thu Nov 20 21:50:50 2008
From: rea-fbsd at codelabs.ru (Eygene Ryabinkin)
Date: Thu Nov 20 21:50:57 2008
Subject: Plaintext recovery attack in SSH, discovered by CPNI?
In-Reply-To: <6p2tlso0g3Xi5suHfErE3rcPs54@Mr6N54GlMnGhD+RQ1Yhx+24IxLk>
References: <6p2tlso0g3Xi5suHfErE3rcPs54@Mr6N54GlMnGhD+RQ1Yhx+24IxLk>
Message-ID:
Me again.
Wed, Nov 19, 2008 at 04:20:58PM +0300, Eygene Ryabinkin wrote:
> Just came across the following list in the oss-security list:
> http://www.cpni.gov.uk/Docs/Vulnerability_Advisory_SSH.txt
For you interest, CVE was created and it has some interesting
links inside (SANS one explains some general trends):
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5161
It seems that some vendors are moving to the CTR encryption mode as the
default one. Does anyone has something to say about this? As I
understand, the advisory from CPNI is public, so there is no point to
refraining from discuissing this in the open lists. OpenSSH people, I
understand that this is not just "two day business", but can you at
least drop a mail that you're investigating this?
Thanks a lot.
--
Eygene
_ ___ _.--. #
\`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, / # while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / # -- FreeBSD Developers handbook
{_.-``-' {_/ #
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-security/attachments/20081121/ae50b59a/attachment.pgp
From edwin at FreeBSD.org Thu Nov 20 21:50:18 2008
From: edwin at FreeBSD.org (edwin@FreeBSD.org)
Date: Thu Nov 20 21:56:11 2008
Subject: ports/129037: [patch] [vuxml] graphics/imlib2: fix CVE-2008-5187
Message-ID: <200811210550.mAL5oH16087548@freefall.freebsd.org>
Synopsis: [patch] [vuxml] graphics/imlib2: fix CVE-2008-5187
Responsible-Changed-From-To: freebsd-ports-bugs->stas
Responsible-Changed-By: edwin
Responsible-Changed-When: Fri Nov 21 05:50:17 UTC 2008
Responsible-Changed-Why:
Over to maintainer (via the GNATS Auto Assign Tool)
http://www.freebsd.org/cgi/query-pr.cgi?pr=129037
From djm at mindrot.org Fri Nov 21 03:28:11 2008
From: djm at mindrot.org (Damien Miller)
Date: Fri Nov 21 04:34:32 2008
Subject: Plaintext recovery attack in SSH, discovered by CPNI?
In-Reply-To:
References: <6p2tlso0g3Xi5suHfErE3rcPs54@Mr6N54GlMnGhD+RQ1Yhx+24IxLk>
Message-ID:
see http://www.openssh.com/txt/cbc.adv
On Fri, 21 Nov 2008, Eygene Ryabinkin wrote:
> Me again.
>
> Wed, Nov 19, 2008 at 04:20:58PM +0300, Eygene Ryabinkin wrote:
> > Just came across the following list in the oss-security list:
> > http://www.cpni.gov.uk/Docs/Vulnerability_Advisory_SSH.txt
>
> For you interest, CVE was created and it has some interesting
> links inside (SANS one explains some general trends):
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5161
>
> It seems that some vendors are moving to the CTR encryption mode as the
> default one. Does anyone has something to say about this? As I
> understand, the advisory from CPNI is public, so there is no point to
> refraining from discuissing this in the open lists. OpenSSH people, I
> understand that this is not just "two day business", but can you at
> least drop a mail that you're investigating this?
>
> Thanks a lot.
> --
> Eygene
> _ ___ _.--. #
> \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard
> / ' ` , __.--' # to read the on-line manual
> )/' _/ \ `-_, / # while single-stepping the kernel.
> `-'" `"\_ ,_.-;_.-\_ ', fsc/as #
> _.-'_./ {_.' ; / # -- FreeBSD Developers handbook
> {_.-``-' {_/ #
>
From rea-fbsd at codelabs.ru Fri Nov 21 05:13:49 2008
From: rea-fbsd at codelabs.ru (Eygene Ryabinkin)
Date: Fri Nov 21 05:13:56 2008
Subject: Plaintext recovery attack in SSH, discovered by CPNI?
In-Reply-To:
References: <6p2tlso0g3Xi5suHfErE3rcPs54@Mr6N54GlMnGhD+RQ1Yhx+24IxLk>
Message-ID:
Damien, good day.
Fri, Nov 21, 2008 at 10:10:32PM +1100, Damien Miller wrote:
> see http://www.openssh.com/txt/cbc.adv
Thanks! Is there some secret place that links to this (and other)
advisory or I should just poll http://openssh.org/txt/? ;))
--
Eygene
_ ___ _.--. #
\`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, / # while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / # -- FreeBSD Developers handbook
{_.-``-' {_/ #
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-security/attachments/20081121/33f0a31a/attachment.pgp
From naddy at mips.inka.de Fri Nov 21 05:26:32 2008
From: naddy at mips.inka.de (Christian Weisgerber)
Date: Fri Nov 21 05:26:45 2008
Subject: Plaintext recovery attack in SSH, discovered by CPNI?
References: <6p2tlso0g3Xi5suHfErE3rcPs54@Mr6N54GlMnGhD+RQ1Yhx+24IxLk>
Message-ID:
Eygene Ryabinkin wrote:
> So, it is interesting what OpenSSH developers can tell about this:
> I had seen no words about this at http://openssh.org/security.html
> and relese notes, so if you can -- please, comment on this.
http://www.openssh.com/txt/cbc.adv
--
Christian "naddy" Weisgerber naddy@mips.inka.de
From rea-fbsd at codelabs.ru Fri Nov 21 05:26:35 2008
From: rea-fbsd at codelabs.ru (Eygene Ryabinkin)
Date: Fri Nov 21 05:26:46 2008
Subject: Plaintext recovery attack in SSH, discovered by CPNI?
In-Reply-To:
References: <6p2tlso0g3Xi5suHfErE3rcPs54@Mr6N54GlMnGhD+RQ1Yhx+24IxLk>
Message-ID:
Damien,
Fri, Nov 21, 2008 at 04:13:43PM +0300, Eygene Ryabinkin wrote:
> Fri, Nov 21, 2008 at 10:10:32PM +1100, Damien Miller wrote:
> > see http://www.openssh.com/txt/cbc.adv
>
> Thanks! Is there some secret place that links to this (and other)
> advisory or I should just poll http://openssh.org/txt/? ;))
I am sorry -- I was not aware that you're in the OpenSSH development
team ;)) The question seems to be a bit stupid ;-/ But still, if
there are some secret places...
--
Eygene
_ ___ _.--. #
\`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, / # while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / # -- FreeBSD Developers handbook
{_.-``-' {_/ #
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-security/attachments/20081121/6045bbd3/attachment.pgp
From rea-fbsd at codelabs.ru Fri Nov 21 07:20:02 2008
From: rea-fbsd at codelabs.ru (Eygene Ryabinkin)
Date: Fri Nov 21 07:20:09 2008
Subject: ports/129050: [vuxml] [patch] audio/libcdaudio: fix CVE-2005-0706
and CVE-2008-5030
Message-ID: <20081121151750.A37A11AF41B@void.codelabs.ru>
>Number: 129050
>Category: ports
>Synopsis: [vuxml] [patch] audio/libcdaudio: fix CVE-2005-0706 and CVE-2008-5030
>Confidential: no
>Severity: serious
>Priority: high
>Responsible: freebsd-ports-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Fri Nov 21 15:20:01 UTC 2008
>Closed-Date:
>Last-Modified:
>Originator: Eygene Ryabinkin
>Release: FreeBSD 7.1-PRERELEASE i386
>Organization:
Code Labs
>Environment:
System: FreeBSD 7.1-PRERELEASE i386
>Description:
There are at least two issues with libcdaudio's CDDB stuff:
http://www.securityfocus.com/bid/12770
http://www.securityfocus.com/bid/32122
-----
Heap-based buffer overflow in the cddb_read_disc_data function in
cddb.c in libcdaudio 0.99.12p2 allows remote attackers to execute
arbitrary code via long CDDB data.
Buffer overflow in discdb.c for grip 3.1.2 allows attackers to cause
a denial of service (crash) and possibly execute arbitrary code by
causing the cddb lookup to return more matches than expected.
-----
The latter programming error also lives inside libcdaudio's code.
>How-To-Repeat:
See
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0706
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5030
>Fix:
The following patch brings the fixes to the FreeBSD port:
--- libcdaudio-0.99.12p2-fix-CVE-2008-5030.2005-0706.diff begins here ---
diff -urN ./Makefile ../libcdaudio/Makefile
--- ./Makefile 2008-11-21 17:04:39.000000000 +0300
+++ ../libcdaudio/Makefile 2008-11-21 17:04:52.000000000 +0300
@@ -7,7 +7,7 @@
PORTNAME= libcdaudio
PORTVERSION= 0.99.12p2
-PORTREVISION= 1
+PORTREVISION= 2
CATEGORIES= audio
MASTER_SITES= ${MASTER_SITE_SOURCEFORGE}
MASTER_SITE_SUBDIR= ${PORTNAME}
diff -urN ./files/patch-CVE-2008-5030.2005-0706 ../libcdaudio/files/patch-CVE-2008-5030.2005-0706
--- ./files/patch-CVE-2008-5030.2005-0706 1970-01-01 03:00:00.000000000 +0300
+++ ../libcdaudio/files/patch-CVE-2008-5030.2005-0706 2008-11-21 17:45:03.000000000 +0300
@@ -0,0 +1,58 @@
+CVE-2008-5030 fix
+=================
+
+Fix contents: second hunk for src/cddb.c
+Obtained from: http://sourceforge.net/tracker/download.php?group_id=27134&atid=389442&file_id=148743&aid=1288043
+
+
+CVE-2005-0706 fix
+=================
+
+Fix contents: first hunk for src/cddb.c and complete diff for src/coverart.c
+Based on: http://sourceforge.net/tracker/download.php?group_id=3714&atid=303714&file_id=124892&aid=1160134
+
+--- src/cddb.c.orig 2004-09-09 05:26:39.000000000 +0400
++++ src/cddb.c 2008-11-21 17:33:50.000000000 +0300
+@@ -1052,7 +1052,8 @@
+ }
+
+ query->query_matches = 0;
+- while(!cddb_read_line(sock, inbuffer, 256)) {
++ while(query->query_matches < MAX_INEXACT_MATCHES &&
++ !cddb_read_line(sock, inbuffer, 256)) {
+ slashed = 0;
+ if(strchr(inbuffer, '/') != NULL && parse_disc_artist) {
+ index = 0;
+@@ -1601,7 +1602,7 @@
+ return -1;
+ }
+
+- if((inbuffer = malloc(256)) == NULL) {
++ if((inbuffer = malloc(512)) == NULL) {
+ free(root_dir);
+ free(file);
+ return -1;
+--- src/coverart.c.orig 2008-11-21 17:36:39.000000000 +0300
++++ src/coverart.c 2008-11-21 17:39:41.000000000 +0300
+@@ -131,7 +131,9 @@
+ }
+ } else if(strncmp(line, "Album", 5) == 0) {
+ long n = strtol((char *)line + 5, NULL, 10);
+- if(parse_disc_artist && strchr(procbuffer, '/') != NULL) {
++ if(n >= MAX_INEXACT_MATCHES) {
++ // Too much data, can't store it
++ } else if(parse_disc_artist && strchr(procbuffer, '/') != NULL) {
+ strtok(procbuffer, "/");
+ strncpy(query->query_list[n].list_artist, procbuffer,
+ (strlen(procbuffer) < 64) ? (strlen(procbuffer) - 1) : 64);
+@@ -143,7 +145,9 @@
+ }
+ } else if(strncmp(line, "Url", 3) == 0) {
+ long n = strtol((char *)line + 3, NULL, 10);
+- cddb_process_url(&query->query_list[n].list_host, procbuffer);
++ if (n < MAX_INEXACT_MATCHES) {
++ cddb_process_url(&query->query_list[n].list_host, procbuffer);
++ }
+ }
+
+ return;
--- libcdaudio-0.99.12p2-fix-CVE-2008-5030.2005-0706.diff ends here ---
The fix for CVE-2005-0706 was based on the Grip's original fix [1], but
I had found that the same programming error exists in the coverart.c.
Now I am trying to investigate if this error is known (with the Mandriva
security officer, since I had initially found this issue via reading
MDVSA-2008:233 [2]). Still, issue in coverart.c seem to be of a same
kind as the cddb.c's one.
[1] http://sourceforge.net/tracker/index.php?func=detail&aid=1160134&group_id=3714&atid=303714
[2] http://www.mandriva.com/en/security/advisories?name=MDVSA-2008:233
The following VuXML entry should be evaluated and added:
--- vuln.xml begins here ---
libcdaudio -- remote buffer overflow and code execution
libcdaudio
0.99.12p2_2
SecurityFocus vulnerability database says:
The 'libcdaudio' library is prone to a remote heap
buffer-overflow vulnerability because it fails to perform
adequate boundary checks on user-supplied input before
copying it to an insufficiently sized buffer.
Attackers can exploit this issue to execute arbitrary
code in the context of an application that uses the library.
Failed attacks will cause denial-of-service conditions.
This issue affects libcdaudio 0.99.12p2; other versions
may also be affected.
A buffer-overflow in Grip occurs when the software
processes a response to a CDDB query that has more than 16
matches.
To exploit this issue, an attacker must be able to
influence the response to a CDDB query, either by controlling
a malicious CDDB server or through some other means.
Successful exploits will allow arbitrary code to run.
The same code as for the Grip vulnerability was found
in the libcdaudio library, so it is affected by the simular
issues.
CVE-2008-5030
CVE-2005-0706
32122
12770
http://sourceforge.net/tracker/index.php?func=detail&aid=1288043&group_id=27134&atid=389442
http://sourceforge.net/tracker/index.php?func=detail&aid=834724&group_id=3714&atid=103714
2008-11-05
--- vuln.xml ends here ---
>Release-Note:
>Audit-Trail:
>Unformatted:
From edwin at FreeBSD.org Fri Nov 21 07:20:18 2008
From: edwin at FreeBSD.org (edwin@FreeBSD.org)
Date: Fri Nov 21 08:47:09 2008
Subject: ports/129050: [vuxml] [patch] audio/libcdaudio: fix
CVE-2005-0706 and CVE-2008-5030
Message-ID: <200811211520.mALFKHWq037161@freefall.freebsd.org>
Synopsis: [vuxml] [patch] audio/libcdaudio: fix CVE-2005-0706 and CVE-2008-5030
Responsible-Changed-From-To: freebsd-ports-bugs->novel
Responsible-Changed-By: edwin
Responsible-Changed-When: Fri Nov 21 15:20:17 UTC 2008
Responsible-Changed-Why:
Over to maintainer (via the GNATS Auto Assign Tool)
http://www.freebsd.org/cgi/query-pr.cgi?pr=129050
From dinoex at FreeBSD.org Fri Nov 21 10:46:13 2008
From: dinoex at FreeBSD.org (dinoex@FreeBSD.org)
Date: Fri Nov 21 14:25:10 2008
Subject: ports/129001: [vuxml] [patch] print/cups-base: fix NULL-pointer
dereference
Message-ID: <200811211846.mALIkCQK092821@freefall.freebsd.org>
Synopsis: [vuxml] [patch] print/cups-base: fix NULL-pointer dereference
State-Changed-From-To: open->feedback
State-Changed-By: dinoex
State-Changed-When: Fri Nov 21 19:45:23 CET 2008
State-Changed-Why:
The patch do not apply.
patch <1
Hmm... Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -urN ./Makefile ../cups-base/Makefile
|--- ./Makefile 2008-11-20 02:48:10.000000000 +0300
|+++ ../cups-base/Makefile 2008-11-20 03:07:03.000000000 +0300
--------------------------
Patching file ./Makefile using Plan A...
Hunk #1 failed at 7.
1 out of 1 hunks failed--saving rejects to ./Makefile.rej
Hmm... The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -urN ./files/patch-fix-subscriptions-null-dereference ../cups-base/fil=
|es/patch-fix-subscriptions-null-dereference
|--- ./files/patch-fix-subscriptions-null-dereference 1970-01-01 03:00:00.00=
|0000000 +0300
|+++ ../cups-base/files/patch-fix-subscriptions-null-dereference 2008-11-20 =
|11:33:59.000000000 +0300
--------------------------
(Creating file ./files/patch-fix-subscriptions-null-dereference...)
Patching file ./files/patch-fix-subscriptions-null-dereference using Plan A...
patch: **** malformed patch at line 24: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
dm@home3:/usr/ports/current/cups-base$ ls -tlr
total 430
http://www.freebsd.org/cgi/query-pr.cgi?pr=129001
From rea-fbsd at codelabs.ru Fri Nov 21 23:18:03 2008
From: rea-fbsd at codelabs.ru (Eygene Ryabinkin)
Date: Fri Nov 21 23:18:38 2008
Subject: ports/129001: [vuxml] [patch] print/cups-base: fix
NULL-pointer dereference
In-Reply-To: <200811211846.mALIkCQK092821@freefall.freebsd.org>
References: <200811211846.mALIkCQK092821@freefall.freebsd.org>
Message-ID:
Skipped content of type multipart/mixed-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-security/attachments/20081122/d2e40b77/attachment.pgp
From rea-fbsd at codelabs.ru Sat Nov 22 12:01:40 2008
From: rea-fbsd at codelabs.ru (Eygene Ryabinkin)
Date: Sat Nov 22 12:01:48 2008
Subject: [vuxml] graphics/optipng: document CVE-2008-5101
Message-ID: <20081122200136.432B3F181F@phoenix.codelabs.ru>
>Submitter-Id: current-users
>Originator: Eygene Ryabinkin
>Organization: Code Labs
>Confidential: no
>Synopsis: [vuxml] graphics/optipng: document CVE-2008-5101
>Severity: serious
>Priority: high
>Category: ports
>Class: sw-bug
>Release: FreeBSD 7.1-PRERELEASE i386
>Environment:
System: FreeBSD 7.1-PRERELEASE i386
>Description:
Buffer overflow in the OptiPNG BMP file handling was discovered. The
code in question exists even in the 0.5.4, so, while it is questionable
if such an old version can be attacked with the original exploit, I
think that 0.5.4 has this vulnerability too. Have no direct evidence
though.
>How-To-Repeat:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5101
http://secunia.com/advisories/32651
>Fix:
The following VuXML entry should be evaluated and added:
--- vuln.xml begins here ---
optipng -- arbitrary code execution via crafted BMP image
optipng
1.6.2
Secunia reports:
A vulnerability has been reported in OptiPNG, which
potentially can be exploited by malicious people to compromise
a user's system.
The vulnerability is caused due to a boundary error in
the BMP reader and can be exploited to cause a buffer
overflow by tricking a user into processing a specially
crafted file.
Successful exploitation may allow execution of arbitrary
code.
The vulnerability is reported in versions prior to 0.6.2.
CVE-2008-5101
http://secunia.com/advisories/32651
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=505399
http://optipng.sourceforge.net/
2008-11-11
--- vuln.xml ends here ---
Please, note that there is PR ports/128877 that updates port to 0.6.2
and this version isn't vulnerable. I feel that the PR severity can be
raised due to the found vulnerability.
From miwi at FreeBSD.org Sat Nov 22 14:50:28 2008
From: miwi at FreeBSD.org (miwi@FreeBSD.org)
Date: Sat Nov 22 14:50:34 2008
Subject: ports/128956: [patch] [vuxml] lang/php5 - multiple
vulnerabilities in PHP 5.2.6
Message-ID: <200811222250.mAMMoSA0000296@freefall.freebsd.org>
Synopsis: [patch] [vuxml] lang/php5 - multiple vulnerabilities in PHP 5.2.6
Responsible-Changed-From-To: miwi->ale
Responsible-Changed-By: miwi
Responsible-Changed-When: Sat Nov 22 22:49:56 UTC 2008
Responsible-Changed-Why:
Over to maintainer,
please let me know when you commit this patches I will prepare a vuxml
entry.
- Martin
http://www.freebsd.org/cgi/query-pr.cgi?pr=128956
From rea-fbsd at codelabs.ru Sat Nov 22 15:18:23 2008
From: rea-fbsd at codelabs.ru (Eygene Ryabinkin)
Date: Sat Nov 22 15:18:30 2008
Subject: [patch] [vuxml] net/wireshark: fix DoS in SMTP dissector
Message-ID: <20081122231819.50846F181F@phoenix.codelabs.ru>
>Submitter-Id: current-users
>Originator: Eygene Ryabinkin
>Organization: Code Labs
>Confidential: no
>Synopsis: [patch] [vuxml] net/wireshark: fix DoS in SMTP dissector
>Severity: serious
>Priority: high
>Category: ports
>Class: sw-bug
>Release: FreeBSD 7.1-PRERELEASE i386
>Environment:
System: FreeBSD 7.1-PRERELEASE i386
>Description:
Today the DoS possibility for Wireshark was disclosed via BugTraq
list: http://www.securityfocus.com/archive/1/498562/30/0/threaded
Vendor acknowledged the existence of this issue and had already
patched it in Subversion repository:
----- http://wiki.wireshark.org/Development/Roadmap
Complete:
* Rev 24989 & Rev 24994 - Support for RFC 2920 SMTP Command Pipelining,
which also happens to fix a DoS found by researchers at Bkis
-----
>How-To-Repeat:
Look at http://www.securityfocus.com/archive/1/498562/30/0/threaded
and http://wiki.wireshark.org/Development/Roadmap
>Fix:
The following patch will apply the vendor fix from the trunk to the
1.0.4:
--- fix-DoS-in-SMTP-dissector.diff begins here ---
>From 676903bce0030930fa99ce4a9692057c2020c319 Mon Sep 17 00:00:00 2001
From: Eygene Ryabinkin
Date: Sun, 23 Nov 2008 02:04:51 +0300
See http://www.securityfocus.com/archive/1/498562/30/0/threaded for the
description of the vulnerability. The patch was taken from the
Subversion repository of wireshark.
Signed-off-by: Eygene Ryabinkin
---
net/wireshark/Makefile | 2 +-
net/wireshark/files/patch-fix-SMTP-DoS-1.0.4 | 356 ++++++++++++++++++++++++++
2 files changed, 357 insertions(+), 1 deletions(-)
create mode 100644 net/wireshark/files/patch-fix-SMTP-DoS-1.0.4
diff --git a/net/wireshark/Makefile b/net/wireshark/Makefile
index 49de12c..2e21104 100644
--- a/net/wireshark/Makefile
+++ b/net/wireshark/Makefile
@@ -7,7 +7,7 @@
PORTNAME?= wireshark
PORTVERSION= 1.0.4
-PORTREVISION?= 0
+PORTREVISION?= 1
CATEGORIES= net ipv6
MASTER_SITES= http://www.wireshark.org/download/src/ \
http://wireshark.osmirror.nl/download/src/ \
diff --git a/net/wireshark/files/patch-fix-SMTP-DoS-1.0.4 b/net/wireshark/files/patch-fix-SMTP-DoS-1.0.4
new file mode 100644
index 0000000..e5d2e9e
--- /dev/null
+++ b/net/wireshark/files/patch-fix-SMTP-DoS-1.0.4
@@ -0,0 +1,356 @@
+Fix for the SMTP dissector DoS
+
+See: http://www.securityfocus.com/archive/1/498562/30/0/threaded
+Obtained from: http://anonsvn.wireshark.org/viewvc/trunk/epan/dissectors/packet-smtp.c?r1=24989&r2=24988&pathrev=24989&view=patch
+Obtained from: http://anonsvn.wireshark.org/viewvc/trunk/epan/dissectors/packet-smtp.c?r1=24994&r2=24993&pathrev=24994&view=patch
+
+--- epan/dissectors/packet-smtp.c 2008/04/13 16:21:22 24988
++++ epan/dissectors/packet-smtp.c 2008/04/13 16:33:44 24989
+@@ -97,10 +97,6 @@
+ "DATA fragments"
+ };
+
+-/* Define media_type/Content type table */
+-static dissector_table_t media_type_dissector_table;
+-
+-
+ static dissector_handle_t imf_handle = NULL;
+
+ /*
+@@ -175,6 +171,7 @@
+ gint length_remaining;
+ gboolean eom_seen = FALSE;
+ gint next_offset;
++ gint loffset;
+ gboolean is_continuation_line;
+ int cmdlen;
+ fragment_data *frag_msg = NULL;
+@@ -217,21 +214,6 @@
+ * longer than what's in the buffer, so the "tvb_get_ptr()" call
+ * won't throw an exception.
+ */
+- linelen = tvb_find_line_end(tvb, offset, -1, &next_offset,
+- smtp_desegment && pinfo->can_desegment);
+- if (linelen == -1) {
+- /*
+- * We didn't find a line ending, and we're doing desegmentation;
+- * tell the TCP dissector where the data for this message starts
+- * in the data it handed us, and tell it we need one more byte
+- * (we may need more, but we'll try again if what we get next
+- * isn't enough), and return.
+- */
+- pinfo->desegment_offset = offset;
+- pinfo->desegment_len = 1;
+- return;
+- }
+- line = tvb_get_ptr(tvb, offset, linelen);
+
+ frame_data = p_get_proto_data(pinfo->fd, proto_smtp);
+
+@@ -267,6 +249,42 @@
+
+ }
+
++ if(request) {
++ frame_data = se_alloc(sizeof(struct smtp_proto_data));
++
++ frame_data->conversation_id = conversation->index;
++ frame_data->more_frags = TRUE;
++
++ p_add_proto_data(pinfo->fd, proto_smtp, frame_data);
++
++ }
++
++ loffset = offset;
++ while (tvb_offset_exists(tvb, loffset)) {
++
++ linelen = tvb_find_line_end(tvb, loffset, -1, &next_offset,
++ smtp_desegment && pinfo->can_desegment);
++ if (linelen == -1) {
++
++ if(offset == loffset) {
++ /*
++ * We didn't find a line ending, and we're doing desegmentation;
++ * tell the TCP dissector where the data for this message starts
++ * in the data it handed us, and tell it we need one more byte
++ * (we may need more, but we'll try again if what we get next
++ * isn't enough), and return.
++ */
++ pinfo->desegment_offset = loffset;
++ pinfo->desegment_len = 1;
++ return;
++ }
++ else {
++ linelen = tvb_length_remaining(tvb, loffset);
++ next_offset = loffset + linelen;
++ }
++ }
++ line = tvb_get_ptr(tvb, loffset, linelen);
++
+ /*
+ * Check whether or not this packet is an end of message packet
+ * We should look for CRLF.CRLF and they may be split.
+@@ -282,16 +300,16 @@
+ * .CRLF at the begining of the same packet.
+ */
+
+- if ((request_val->crlf_seen && tvb_strneql(tvb, offset, ".\r\n", 3) == 0) ||
+- tvb_strneql(tvb, offset, "\r\n.\r\n", 5) == 0) {
++ if ((request_val->crlf_seen && tvb_strneql(tvb, loffset, ".\r\n", 3) == 0) ||
++ tvb_strneql(tvb, loffset, "\r\n.\r\n", 5) == 0) {
+
+ eom_seen = TRUE;
+
+- }
++ }
+
+- length_remaining = tvb_length_remaining(tvb, offset);
+- if (length_remaining == tvb_reported_length_remaining(tvb, offset) &&
+- tvb_strneql(tvb, offset + length_remaining - 2, "\r\n", 2) == 0) {
++ length_remaining = tvb_length_remaining(tvb, loffset);
++ if (length_remaining == tvb_reported_length_remaining(tvb, loffset) &&
++ tvb_strneql(tvb, loffset + length_remaining - 2, "\r\n", 2) == 0) {
+
+ request_val->crlf_seen = TRUE;
+
+@@ -310,11 +328,6 @@
+
+ if (request) {
+
+- frame_data = se_alloc(sizeof(struct smtp_proto_data));
+-
+- frame_data->conversation_id = conversation->index;
+- frame_data->more_frags = TRUE;
+-
+ if (request_val->reading_data) {
+ /*
+ * This is message data.
+@@ -329,6 +342,9 @@
+ */
+ frame_data->pdu_type = SMTP_PDU_EOM;
+ request_val->reading_data = FALSE;
++
++ break;
++
+ } else {
+ /*
+ * Message data with no EOM.
+@@ -340,7 +356,7 @@
+ * We are handling a BDAT message.
+ * Check if we have reached end of the data chunk.
+ */
+- request_val->msg_read_len += tvb_length_remaining(tvb, offset);
++ request_val->msg_read_len += tvb_length_remaining(tvb, loffset);
+
+ if (request_val->msg_read_len == request_val->msg_tot_len) {
+ /*
+@@ -356,6 +372,8 @@
+ */
+ frame_data->more_frags = FALSE;
+ }
++
++ break; /* no need to go through the remaining lines */
+ }
+ }
+ }
+@@ -446,12 +464,15 @@
+ frame_data->pdu_type = request_val->data_seen ? SMTP_PDU_MESSAGE : SMTP_PDU_CMD;
+
+ }
+-
+ }
++ }
+
+- p_add_proto_data(pinfo->fd, proto_smtp, frame_data);
++ /*
++ * Step past this line.
++ */
++ loffset = next_offset;
+
+- }
++ }
+ }
+
+ /*
+@@ -463,6 +484,7 @@
+ col_set_str(pinfo->cinfo, COL_PROTOCOL, "SMTP");
+
+ if (check_col(pinfo->cinfo, COL_INFO)) { /* Add the appropriate type here */
++ col_clear(pinfo->cinfo, COL_INFO);
+
+ /*
+ * If it is a request, we have to look things up, otherwise, just
+@@ -477,21 +499,38 @@
+ case SMTP_PDU_MESSAGE:
+
+ length_remaining = tvb_length_remaining(tvb, offset);
+- col_set_str(pinfo->cinfo, COL_INFO, smtp_data_desegment ? "DATA fragment" : "Message Body");
++ col_set_str(pinfo->cinfo, COL_INFO, smtp_data_desegment ? "C: DATA fragment" : "C: Message Body");
+ col_append_fstr(pinfo->cinfo, COL_INFO, ", %d byte%s", length_remaining,
+ plurality (length_remaining, "", "s"));
+ break;
+
+ case SMTP_PDU_EOM:
+
+- col_add_fstr(pinfo->cinfo, COL_INFO, "EOM: %s",
+- format_text(line, linelen));
++ col_set_str(pinfo->cinfo, COL_INFO, "C: .");
++
+ break;
+
+ case SMTP_PDU_CMD:
+
+- col_add_fstr(pinfo->cinfo, COL_INFO, "Command: %s",
+- format_text(line, linelen));
++ loffset = offset;
++ while (tvb_offset_exists(tvb, loffset)) {
++ /*
++ * Find the end of the line.
++ */
++ linelen = tvb_find_line_end(tvb, loffset, -1, &next_offset, FALSE);
++ line = tvb_get_ptr(tvb, loffset, linelen);
++
++ if(loffset == offset)
++ col_append_fstr(pinfo->cinfo, COL_INFO, "C: %s",
++ format_text(line, linelen));
++ else {
++ col_append_fstr(pinfo->cinfo, COL_INFO, " | %s",
++ format_text(line, linelen));
++ }
++
++ loffset = next_offset;
++
++ }
+ break;
+
+ }
+@@ -499,9 +538,24 @@
+ }
+ else {
+
+- col_add_fstr(pinfo->cinfo, COL_INFO, "Response: %s",
+- format_text(line, linelen));
++ loffset = offset;
++ while (tvb_offset_exists(tvb, loffset)) {
++ /*
++ * Find the end of the line.
++ */
++ linelen = tvb_find_line_end(tvb, loffset, -1, &next_offset, FALSE);
++ line = tvb_get_ptr(tvb, loffset, linelen);
++
++ if(loffset == offset)
++ col_append_fstr(pinfo->cinfo, COL_INFO, "S: %s",
++ format_text(line, linelen));
++ else {
++ col_append_fstr(pinfo->cinfo, COL_INFO, " | %s",
++ format_text(line, linelen));
++ }
+
++ loffset = next_offset;
++ }
+ }
+ }
+
+@@ -556,8 +610,7 @@
+ * DATA command this terminates before sending another
+ * request, but we should probably handle it.
+ */
+- proto_tree_add_text(smtp_tree, tvb, offset, linelen,
+- "EOM: %s", format_text(line, linelen));
++ proto_tree_add_text(smtp_tree, tvb, offset, linelen, "C: .");
+
+ if(smtp_data_desegment) {
+
+@@ -578,6 +631,15 @@
+ * previous command before sending another request, but we
+ * should probably handle it.
+ */
++
++ loffset = offset;
++ while (tvb_offset_exists(tvb, loffset)) {
++
++ /*
++ * Find the end of the line.
++ */
++ linelen = tvb_find_line_end(tvb, loffset, -1, &next_offset, FALSE);
++
+ if (linelen >= 4)
+ cmdlen = 4;
+ else
+@@ -587,16 +649,16 @@
+ /*
+ * Put the command line into the protocol tree.
+ */
+- ti = proto_tree_add_text(smtp_tree, tvb, offset, next_offset - offset,
++ ti = proto_tree_add_text(smtp_tree, tvb, loffset, next_offset - loffset,
+ "Command: %s",
+- tvb_format_text(tvb, offset, next_offset - offset));
++ tvb_format_text(tvb, loffset, next_offset - loffset));
+ cmdresp_tree = proto_item_add_subtree(ti, ett_smtp_cmdresp);
+
+ proto_tree_add_item(cmdresp_tree, hf_smtp_req_command, tvb,
+- offset, cmdlen, FALSE);
++ loffset, cmdlen, FALSE);
+ if (linelen > 5) {
+ proto_tree_add_item(cmdresp_tree, hf_smtp_req_parameter, tvb,
+- offset + 5, linelen - 5, FALSE);
++ loffset + 5, linelen - 5, FALSE);
+ }
+
+ if (smtp_data_desegment && !frame_data->more_frags) {
+@@ -605,6 +667,13 @@
+ frag_msg = fragment_end_seq_next (pinfo, frame_data->conversation_id, smtp_data_segment_table,
+ smtp_data_reassembled_table);
+ }
++
++ /*
++ * Step past this line.
++ */
++ loffset = next_offset;
++
++ }
+ }
+
+ if (smtp_data_desegment) {
+@@ -689,8 +758,8 @@
+ /*
+ * If it's not a continuation line, quit.
+ */
+- if (!is_continuation_line)
+- break;
++ /* if (!is_continuation_line)
++ break; */
+
+ }
+
+@@ -771,7 +840,6 @@
+ };
+ module_t *smtp_module;
+
+-
+ proto_smtp = proto_register_protocol("Simple Mail Transfer Protocol",
+ "SMTP", "smtp");
+
+@@ -808,11 +876,6 @@
+ dissector_add("tcp.port", TCP_PORT_SMTP, smtp_handle);
+ dissector_add("tcp.port", TCP_PORT_SUBMISSION, smtp_handle);
+
+- /*
+- * Get the content type and Internet media type table
+- */
+- media_type_dissector_table = find_dissector_table("media_type");
+-
+ /* find the IMF dissector */
+ imf_handle = find_dissector("imf");
+
+--- epan/dissectors/packet-smtp.c 2008/04/13 16:55:56 24993
++++ epan/dissectors/packet-smtp.c 2008/04/13 16:58:57 24994
+@@ -167,7 +167,7 @@
+ struct smtp_request_val *request_val;
+ const guchar *line;
+ guint32 code;
+- int linelen;
++ int linelen = 0;
+ gint length_remaining;
+ gboolean eom_seen = FALSE;
+ gint next_offset;
--
1.6.0.4
--- fix-DoS-in-SMTP-dissector.diff ends here ---
I had briefly tested it and it works for me.
The following VuXML entry should be evaluated and added:
--- vuln.xml begins here ---
wireshark -- DoS in the SMTP dissector module
wireshark
wireshark-lite
1.0.4_1
Bach Khoa from Internetwork Security Center reports:
On Nov 2008, Security Vulnerability Research Team of
Bkis (SVRT-Bkis) has detected a vulnerability underlying
WireShark 1.0.4 (lastest version).
The flaw is in the function processing SMTP protocol and
enables hacker to perform a DoS attack by sending a SMTP
request with large content to port 25. The application then
enter a large loop and cannot do anything else.
http://www.securityfocus.com/archive/1/498562/30/0/threaded
http://wiki.wireshark.org/Development/Roadmap
2008-11-22
--- vuln.xml ends here ---
From miwi at FreeBSD.org Sun Nov 23 00:55:49 2008
From: miwi at FreeBSD.org (miwi@FreeBSD.org)
Date: Sun Nov 23 00:55:56 2008
Subject: ports/128999: [vuxml] [patch] update audio/streamripper to
1.64.0, fix CVE-2008-4829
Message-ID: <200811230855.mAN8tmXo091500@freefall.freebsd.org>
Synopsis: [vuxml] [patch] update audio/streamripper to 1.64.0, fix CVE-2008-4829
State-Changed-From-To: open->closed
State-Changed-By: miwi
State-Changed-When: Sun Nov 23 08:55:48 UTC 2008
State-Changed-Why:
Committed. Thanks!
http://www.freebsd.org/cgi/query-pr.cgi?pr=128999
From ltning at anduin.net Sun Nov 23 08:41:44 2008
From: ltning at anduin.net (=?ISO-8859-1?Q?Eirik_=D8verby?=)
Date: Sun Nov 23 08:41:55 2008
Subject: Dropping syn+fin replies, but not really?
Message-ID:
Hi all,
I have a FreeBSD based firewall (pfsense) and, behind it, a few dozen
FreeBSD servers. Now we're required to run external security scans
(nessus++) on some of the hosts, and they constantly come back with a
"high" or "medium" severity problem: The host replies to TCP packets
with SYN+FIN set.
Problem: Both the firewall (FreeBSD 6.2-based pfSense 1.2) and the
host in question (recent FreeBSD 7.2-PRERELEASE) have
net.inet.tcp.drop_synfin=1 - I would therefore expect this to be a non-
issue.
Have I missed something important? Apart from this the hosts and
services get away without any serious issues, but the security audit
company insists this so-called hole to be closed.
Anyone?
Thanks,
/Eirik
From rea-fbsd at codelabs.ru Sun Nov 23 10:44:53 2008
From: rea-fbsd at codelabs.ru (Eygene Ryabinkin)
Date: Sun Nov 23 10:45:01 2008
Subject: [vuxml] print/hplip: document CVE-2008-2940 and CVE-2008-2941
Message-ID: <20081123184449.6801AF181D@phoenix.codelabs.ru>
>Submitter-Id: current-users
>Originator: Eygene Ryabinkin
>Organization: Code Labs
>Confidential: no
>Synopsis: [vuxml] print/hplip: document CVE-2008-2940 and CVE-2008-2941
>Severity: serious
>Priority: high
>Category: ports
>Class: sw-bug
>Release: FreeBSD 7.1-PRERELEASE i386
>Environment:
System: FreeBSD 7.1-PRERELEASE i386
>Description:
Multiple vulnerabilities were discovered in the hplip 1.6.7 [1]. I had
analyzed RedHat patches [2] and [3]: first two (CVE-2008-2940) apply
"as-is" to FreeBSD's port (2.8.2_2) and the second one (CVE-2008-2941)
contains many fixes to the code that exists in 2.8.2_2 too. So, I am
counting current FreeBSD port as vulnerable to both attacks. Moreover,
I had traced the vulnerabilities through the release sources: proper
device_uri handling was introduced in 2.8.4 and parser fragility in
hpssd.py was eliminated in the same version, because hpssd was converted
to a systray application. So, 2.8.4 and higher should not be vulnerable
to the described attacks.
[1] http://www.securityfocus.com/bid/30683
[2] https://bugzilla.redhat.com/show_bug.cgi?id=455235
[3] https://bugzilla.redhat.com/show_bug.cgi?id=457052
>How-To-Repeat:
Look at the above references.
>Fix:
The following VuXML entry should be evaluated and added:
--- vuln.xml begins here ---
hplip -- multiple vulnerabilities in hpssd component
hplip
2.8.4
SecurityFocus database says:
HP Linux Imaging and Printing System (HPLIP) is prone
to multiple vulnerabilities, including privilege-escalation
and denial-of-service issues.
Exploiting the privilege-escalation vulnerability may
allow attackers to perform certain actions with elevated
privileges. Successful exploits of the denial-of-service
issue will cause the 'hpssd' process to crash, denying
service to legitimate users.
These issues affect HPLIP 1.6.7; other versions may also
be affected.
CVE-2008-2940
CVE-2008-2941
30683
https://bugzilla.redhat.com/show_bug.cgi?id=457052
https://bugzilla.redhat.com/show_bug.cgi?id=455235
2008-08-12
--- vuln.xml ends here ---
From rea-fbsd at codelabs.ru Sun Nov 23 12:22:27 2008
From: rea-fbsd at codelabs.ru (Eygene Ryabinkin)
Date: Sun Nov 23 12:22:40 2008
Subject: ports/129097: [vuxml] print/hplip: document CVE-2008-2940 and
CVE-2008-2941
In-Reply-To: <200811231850.mANIo09F042711@freefall.freebsd.org>
References: <20081123184449.6801AF181D@phoenix.codelabs.ru>
<200811231850.mANIo09F042711@freefall.freebsd.org>
Message-ID: <6rQsez7wYkguGr+AMLr6LWOVTxk@iXA9ZWPrtc2I2BMzBXoToMd7YdQ>
Martin Wilke asked me if I am planning to update the port. My original
intention was to wait for a 2.8.10 (I am aware of ports/128914, but, to
my regret, it contains no patch now), but as the quick fix I had ported
RedHat's patches to the current port version.
Please note that the handling of alerts had been changed: now all alert
configuration is stored in /etc/hp/alers.conf and isn't
user-controllable anymore.
And I had to mention that whilst I had tested the port for building
and daemon for starting properly, I have no real hardware to test the
thing. So maintainer's testing is needed.
--
Eygene
_ ___ _.--. #
\`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, / # while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / # -- FreeBSD Developers handbook
{_.-``-' {_/ #
-------------- next part --------------
A non-text attachment was scrubbed...
Name: apply-fixes-for-CVE-2008-2940-and-CVE-2941.diff
Type: text/x-diff
Size: 13600 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-security/attachments/20081123/0d415f47/apply-fixes-for-CVE-2008-2940-and-CVE-2941.bin
From rea-fbsd at codelabs.ru Sun Nov 23 12:43:07 2008
From: rea-fbsd at codelabs.ru (Eygene Ryabinkin)
Date: Sun Nov 23 12:43:14 2008
Subject: Dropping syn+fin replies, but not really?
In-Reply-To:
References:
Message-ID: <+ug4ae9RHVVTC7ztvaDEPTyd/iQ@iXA9ZWPrtc2I2BMzBXoToMd7YdQ>
Eirik, good day.
Sun, Nov 23, 2008 at 05:03:15PM +0100, Eirik ?verby wrote:
> I have a FreeBSD based firewall (pfsense) and, behind it, a few dozen
> FreeBSD servers. Now we're required to run external security scans
> (nessus++) on some of the hosts, and they constantly come back with a
> "high" or "medium" severity problem: The host replies to TCP packets
> with SYN+FIN set.
>
> Problem: Both the firewall (FreeBSD 6.2-based pfSense 1.2) and the
> host in question (recent FreeBSD 7.2-PRERELEASE) have
> net.inet.tcp.drop_synfin=1 - I would therefore expect this to be a non-
> issue.
First of all, (if I am correct) your firewall's setting for drop_synfin
isn't relevant for the packets that are traversing the firewall: TCP
input layer drops these and firewall isn't using this layer.
The easy way to identify if there are replies to SYN+FIN is to spawn
tcpdump on the firewall and see what's going on. It may be well so that
the some sort of scrubbing/modulation is done on the firewall, so when
firewall notices that the SYN + FIN is blackholed, it generates RST by
itself or just blocks SYN + FIN by itself, but sends RST. I am making
guesses here, because I can't test it just now and I have no idea about
your setup.
If I remember correctly, pf is used on the pfSense, so you can easily
block SYN + FIN on the ingress port(s):
-----
block in quick on $ingress proto tcp from any to \
flags SF/ASF
-----
--
Eygene
_ ___ _.--. #
\`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, / # while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / # -- FreeBSD Developers handbook
{_.-``-' {_/ #
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-security/attachments/20081123/f3e16021/attachment.pgp
From pieter at thelostparadise.com Sun Nov 23 09:53:07 2008
From: pieter at thelostparadise.com (Pieter de Boer)
Date: Sun Nov 23 18:31:17 2008
Subject: Dropping syn+fin replies, but not really?
In-Reply-To:
References:
Message-ID: <49299876.4020702@thelostparadise.com>
Eirik ?verby wrote:
> I have a FreeBSD based firewall (pfsense) and, behind it, a few dozen
> FreeBSD servers. Now we're required to run external security scans
> (nessus++) on some of the hosts, and they constantly come back with a
> "high" or "medium" severity problem: The host replies to TCP packets
> with SYN+FIN set.
I'd consider this at most a 'low' severity problem.
> Problem: Both the firewall (FreeBSD 6.2-based pfSense 1.2) and the host
> in question (recent FreeBSD 7.2-PRERELEASE) have
> net.inet.tcp.drop_synfin=1 - I would therefore expect this to be a
> non-issue.
Given security tools' (including Nessus') track records of false
positives, I wouldn't be surprised if this was one of them.
> Have I missed something important? Apart from this the hosts and
> services get away without any serious issues, but the security audit
> company insists this so-called hole to be closed.
It's not a hole, but could possibly aid in bypassing filtering rules
(which is quite unlikely in this day and age). It may be wise to find a
security company that knows how to interpret and verify Nessus output.
If you want to do verification yourself, you could try the following:
- Run tcpdump on one of the servers and on the firewall
- Run nmap from an external host using the '--scanflags SYNFIN' flag
with destination the server.
You can let tcpdump only show specific ports and source/destination
addresses. It's probably useful to use nmap to scan both ports you know
to be open and in use and ports that are filtered. Using the -p option
to nmap, you can specify which ports to scan.
Perform the nmap scan and look at the tcpdump output to see how your
firewall and/or server react.
G'luck,
Pieter
From amistry at am-productions.biz Sun Nov 23 12:20:40 2008
From: amistry at am-productions.biz (Anish Mistry)
Date: Sun Nov 23 18:31:26 2008
Subject: ports/129097: [vuxml] print/hplip: document CVE-2008-2940 and
CVE-2008-2941
In-Reply-To: <20081123184449.6801AF181D@phoenix.codelabs.ru>
References: <20081123184449.6801AF181D@phoenix.codelabs.ru>
Message-ID: <200811231446.43728.amistry@am-productions.biz>
On Sunday 23 November 2008, Eygene Ryabinkin wrote:
> >Number: 129097
> >Category: ports
> >Synopsis: [vuxml] print/hplip: document CVE-2008-2940 and
> > CVE-2008-2941 Confidential: no
> >Severity: serious
> >Priority: high
> >Responsible: freebsd-ports-bugs
> >State: open
> >Quarter:
> >Keywords:
> >Date-Required:
> >Class: sw-bug
> >Submitter-Id: current-users
> >Arrival-Date: Sun Nov 23 18:50:00 UTC 2008
> >Closed-Date:
> >Last-Modified:
> >Originator: Eygene Ryabinkin
> >Release: FreeBSD 7.1-PRERELEASE i386
> >Organization:
Commit it.
--
Anish Mistry
amistry@am-productions.biz
AM Productions http://am-productions.biz/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-security/attachments/20081123/8a9e5a8b/attachment.pgp
From rea-fbsd at codelabs.ru Sun Nov 23 22:45:58 2008
From: rea-fbsd at codelabs.ru (Eygene Ryabinkin)
Date: Sun Nov 23 22:46:05 2008
Subject: ports/129097: [vuxml] print/hplip: document CVE-2008-2940 and
CVE-2008-2941
In-Reply-To: <200811231446.43728.amistry@am-productions.biz>
References: <20081123184449.6801AF181D@phoenix.codelabs.ru>
<200811231446.43728.amistry@am-productions.biz>
Message-ID:
Anish, good day.
Sun, Nov 23, 2008 at 02:46:26PM -0500, Anish Mistry wrote:
> On Sunday 23 November 2008, Eygene Ryabinkin wrote:
> > >Number: 129097
> > >Category: ports
> > >Synopsis: [vuxml] print/hplip: document CVE-2008-2940 and
> > > CVE-2008-2941 Confidential: no
> > >Severity: serious
> > >Priority: high
> > >Responsible: freebsd-ports-bugs
> > >State: open
> > >Quarter:
> > >Keywords:
> > >Date-Required:
> > >Class: sw-bug
> > >Submitter-Id: current-users
> > >Arrival-Date: Sun Nov 23 18:50:00 UTC 2008
> > >Closed-Date:
> > >Last-Modified:
> > >Originator: Eygene Ryabinkin
> > >Release: FreeBSD 7.1-PRERELEASE i386
> > >Organization:
>
> Commit it.
That's fine, thanks. But yesterday I had sent a patch that fixes the
vulnerabilities for 2.8.2. What do you think about it? Could you test
the patch? The VuXML entry details depend on this: I wrote that
hplip >= 2.8.4 aren't vulnerable, but if you'll approve the patch that
upgrades to 2.8.2_3, then VuXML entry should be corrected.
Thanks again!
--
Eygene
_ ___ _.--. #
\`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, / # while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / # -- FreeBSD Developers handbook
{_.-``-' {_/ #
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-security/attachments/20081124/fda90481/attachment.pgp
From des at des.no Mon Nov 24 01:17:51 2008
From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Mon Nov 24 01:17:58 2008
Subject: Dropping syn+fin replies, but not really?
In-Reply-To: ("Eirik
=?utf-8?Q?=C3=98verby=22's?= message of "Sun,
23 Nov 2008 17:03:15 +0100")
References:
Message-ID: <86ej114h4x.fsf@ds4.des.no>
Eirik ?verby writes:
> I have a FreeBSD based firewall (pfsense) and, behind it, a few dozen
> FreeBSD servers. Now we're required to run external security scans
> (nessus++) on some of the hosts, and they constantly come back with a
> "high" or "medium" severity problem: The host replies to TCP packets
> with SYN+FIN set.
>
> Problem: Both the firewall (FreeBSD 6.2-based pfSense 1.2) and the
> host in question (recent FreeBSD 7.2-PRERELEASE) have
> net.inet.tcp.drop_synfin=1 - I would therefore expect this to be a
> non- issue.
I added drop_synfin for one reason and one reason only: it prevented
nmap from reliably identifying a FreeBSD machine, and at the time, that
was sufficient to ward off the kind of script kiddies that would
regularly attack EFNet IRC servers. I don't think SYN+FIN packets were
ever a security issue, and I'm surprised Nessus thinks they are.
Perhaps someone read about drop_synfin and misunderstood its purpose?
Back to the issue at hand: you should use tcpdump to double-check
nessus's findings. Who knows, perhaps drop_synfin was broken in a
network stack reorganization.
DES
--
Dag-Erling Sm?rgrav - des@des.no
From hans at stare.cz Mon Nov 24 01:57:26 2008
From: hans at stare.cz (Jan Stary)
Date: Mon Nov 24 01:57:33 2008
Subject: Dropping syn+fin replies, but not really?
In-Reply-To:
References:
Message-ID: <20081124094425.GA29802@www.stare.cz>
On Nov 23 17:03:15, Eirik ?verby wrote:
> I have a FreeBSD based firewall (pfsense) and, behind it, a few dozen
> FreeBSD servers. Now we're required to run external security scans
> (nessus++) on some of the hosts, and they constantly come back with a
> "high" or "medium" severity problem: The host replies to TCP packets
> with SYN+FIN set.
Aparently, nessus thinks that replying to SYNFIN packets at all is
a problem. But it thinks so because you configured it to thinks so,
right? Or is this hardwired into nessus? Also, why would nessus
sometimes think that it's a "high" severity problem, and at other
times, it's a "medium" severity problem?
> Problem: Both the firewall (FreeBSD 6.2-based pfSense 1.2) and the
> host in question (recent FreeBSD 7.2-PRERELEASE) have
> net.inet.tcp.drop_synfin=1 - I would therefore expect this to be a non-
> issue.
It you configured your firewall and servers to NOT reply to SYNFIN packets,
and the still do, then this is a configuration issue itself.
How you also checked with other tools to find whether your servers reply
to SYNFIN, or do you trust nessus who says so?
Jan
From amistry at am-productions.biz Mon Nov 24 06:56:41 2008
From: amistry at am-productions.biz (Anish Mistry)
Date: Mon Nov 24 07:08:37 2008
Subject: ports/129097: [vuxml] print/hplip: document CVE-2008-2940 and
CVE-2008-2941
In-Reply-To:
References: <20081123184449.6801AF181D@phoenix.codelabs.ru>
<200811231446.43728.amistry@am-productions.biz>
Message-ID: <200811240957.33153.amistry@am-productions.biz>
On Monday 24 November 2008, Eygene Ryabinkin wrote:
> Anish, good day.
>
> That's fine, thanks. But yesterday I had sent a patch that fixes
> the vulnerabilities for 2.8.2. What do you think about it? Could
> you test the patch? The VuXML entry details depend on this: I
> wrote that hplip >= 2.8.4 aren't vulnerable, but if you'll approve
> the patch that upgrades to 2.8.2_3, then VuXML entry should be
> corrected.
>
> Thanks again!
Finally got a around to it. The patches look fine, and it passed my
basic testing. Commit.
Thanks,
--
Anish Mistry
amistry@am-productions.biz
AM Productions http://am-productions.biz/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-security/attachments/20081124/47989086/attachment.pgp
From rea-fbsd at codelabs.ru Mon Nov 24 07:59:30 2008
From: rea-fbsd at codelabs.ru (Eygene Ryabinkin)
Date: Mon Nov 24 07:59:37 2008
Subject: [vuxml] editors/vim: document netrw issues
Message-ID: <20081124155929.073851AF41F@void.codelabs.ru>
>Submitter-Id: current-users
>Originator: Eygene Ryabinkin
>Organization: Code Labs
>Confidential: no
>Synopsis: [vuxml] editors/vim: document netrw issues
>Severity: serious
>Priority: medium
>Category: ports
>Class: sw-bug
>Release: FreeBSD 7.1-PRERELEASE i386
>Environment:
System: FreeBSD 7.1-PRERELEASE i386
>Description:
A bunch of vulnerabilities were discovered in Vim:
http://www.rdancer.org/vulnerablevim-netrw.html
http://www.rdancer.org/vulnerablevim-netrw.v2.html
http://www.rdancer.org/vulnerablevim-netrw.v5.html
http://www.rdancer.org/vulnerablevim-netrw-credentials-dis.html
Some of them affect Vim >=7.0 and < 7.2.
>How-To-Repeat:
Look at the above URLs and read Jan Lieskovsky summary:
http://www.openwall.com/lists/oss-security/2008/10/16/2
>Fix:
The following VuXML entry should be evaluated and added:
--- vuln.xml begins here ---
vim -- multiple vulnerabilities in the netrw module
vim
vim-lite
vim-gtk2
vim-gnome
7.07.2
Jan Minar reports:
Applying the ``D'' to a file with a crafted file name,
or inside a directory with a crafted directory name, can
lead to arbitrary code execution.
Lack of sanitization throughout Netrw can lead to arbitrary
code execution upon opening a directory with a crafted
name.
The Vim Netrw Plugin shares the FTP user name and password
across all FTP sessions. Every time Vim makes a new FTP
connection, it sends the user name and password of the
previous FTP session to the FTP server.
http://www.rdancer.org/vulnerablevim-netrw.html
http://www.rdancer.org/vulnerablevim-netrw.v2.html
http://www.rdancer.org/vulnerablevim-netrw.v5.html
http://www.rdancer.org/vulnerablevim-netrw-credentials-dis.html
http://www.openwall.com/lists/oss-security/2008/10/16/2
CVE-2008-3076
2008-10-16
today
--- vuln.xml ends here ---
From security-advisories at freebsd.org Mon Nov 24 09:47:13 2008
From: security-advisories at freebsd.org (FreeBSD Security Advisories)
Date: Mon Nov 24 09:47:27 2008
Subject: FreeBSD Security Advisory FreeBSD-SA-08:11.arc4random
Message-ID: <200811241747.mAOHlDmZ034725@freefall.freebsd.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
=============================================================================
FreeBSD-SA-08.11.arc4random Security Advisory
The FreeBSD Project
Topic: arc4random(9) predictable sequence vulnerability
Category: core
Module: sys
Announced: 2008-11-24
Credits: Robert Woolley, Mark Murray, Maxim Dounin, Ruslan Ermilov
Affects: All supported versions of FreeBSD.
Corrected: 2008-11-24 17:39:39 UTC (RELENG_7, 7.1-PRERELEASE)
2008-11-24 17:39:39 UTC (RELENG_7_0, 7.0-RELEASE-p6)
2008-11-24 17:39:39 UTC (RELENG_6, 6.4-STABLE)
2008-11-24 17:39:39 UTC (RELENG_6_4, 6.4-RELEASE)
2008-11-24 17:39:39 UTC (RELENG_6_3, 6.3-RELEASE-p6)
CVE Name: CVE-2008-5162
For general information regarding FreeBSD Security Advisories,
including descriptions of the fields above, security branches, and the
following sections, please visit .
I. Background
arc4random(9) is a generic-purpose random number generator based on the
key stream generator of the RC4 cipher. It is expected to be
cryptographically strong, and used throughout the FreeBSD kernel for a
variety of purposes, some of which rely on its cryptographic strength.
arc4random(9) is periodically reseeded with entropy from the FreeBSD
kernel's Yarrow random number generator, which gathers entropy from a
variety of sources including hardware interrupts. During the boot
process, additional entropy is provided to the Yarrow random number
generator from userland, helping to ensure that adequate entropy is
present for cryptographic purposes.
II. Problem Description
When the arc4random(9) random number generator is initialized, there may
be inadequate entropy to meet the needs of kernel systems which rely on
arc4random(9); and it may take up to 5 minutes before arc4random(9) is
reseeded with secure entropy from the Yarrow random number generator.
III. Impact
All security-related kernel subsystems that rely on a quality random
number generator are subject to a wide range of possible attacks for the
300 seconds after boot or until 64k of random data is consumed. The list
includes:
* GEOM ELI providers with onetime keys. When a provider is configured in
a way so that it gets attached at the same time during boot (e.g. it
uses the rc subsystem to initialize) it might be possible for an
attacker to recover the encrypted data.
* GEOM shsec providers. The GEOM shsec subsytem is used to split a shared
secret between two providers so that it can be recovered when both of
them are present. This is done by writing the random sequence to one
of providers while appending the result of the random sequence on the
other host to the original data. If the provider was created within the
first 300 seconds after booting, it might be possible for an attacker
to extract the original data with access to only one of the two providers
between which the secret data is split.
* System processes started early after boot may receive predictable IDs.
* The 802.11 network stack uses arc4random(9) to generate initial vectors
(IV) for WEP encryption when operating in client mode and WEP
authentication challenges when operating in hostap mode, which may be
insecure.
* The IPv4, IPv6 and TCP/UDP protocol implementations rely on a quality
random number generator to produce unpredictable IP packet identifiers,
initial TCP sequence numbers and outgoing port numbers. During the
first 300 seconds after booting, it may be easier for an attacker to
execute IP session hijacking, OS fingerprinting, idle scanning, or in
some cases DNS cache poisoning and blind TCP data injection attacks.
* The kernel RPC code uses arc4random(9) to retrieve transaction
identifiers, which might make RPC clients vulnerable to hijacking
attacks.
IV. Workaround
No workaround is available for affected systems.
V. Solution
NOTE WELL: Any GEOM shsec providers which were created or written to
during the first 300 seconds after booting should be re-created after
applying this security update.
Perform one of the following:
1) Upgrade your vulnerable system to 6-STABLE, or 7-STABLE, or to the
RELENG_7_0, or RELENG_6_3 security branch dated after the correction
date.
2) To patch your present system:
The following patches have been verified to apply to FreeBSD 6.3 and
7.0 systems.
a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.
[FreeBSD 7.x]
# fetch http://security.FreeBSD.org/patches/SA-08:11/arc4random.patch
# fetch http://security.FreeBSD.org/patches/SA-08:11/arc4random.patch.asc
[FreeBSD 6.x]
# fetch http://security.FreeBSD.org/patches/SA-08:11/arc4random6x.patch
# fetch http://security.FreeBSD.org/patches/SA-08:11/arc4random6x.patch.asc
b) Apply the patch.
# cd /usr/src
# patch < /path/to/patch
c) Recompile your kernel as described in
and reboot the
system.
VI. Correction details
The following list contains the revision numbers of each file that was
corrected in FreeBSD.
Branch Revision
Path
- -------------------------------------------------------------------------
RELENG_6
src/sys/dev/random/randomdev.c 1.59.2.2
src/sys/dev/random/randomdev_soft.c 1.11.2.3
RELENG_6_4
src/UPDATING 1.416.2.40.2.2
src/sys/dev/random/randomdev.c 1.59.2.1.8.2
src/sys/dev/random/randomdev_soft.c 1.11.2.2.6.2
RELENG_6_3
src/UPDATING 1.416.2.37.2.11
src/sys/conf/newvers.sh 1.69.2.15.2.10
src/sys/dev/random/randomdev.c 1.59.2.1.6.1
src/sys/dev/random/randomdev_soft.c 1.11.2.2.4.1
RELENG_7
src/sys/dev/random/randomdev.c 1.61.2.1
src/sys/dev/random/randomdev_soft.c 1.15.2.1
RELENG_7_0
src/UPDATING 1.507.2.3.2.10
src/sys/conf/newvers.sh 1.72.2.5.2.10
src/sys/dev/random/randomdev.c 1.61.4.1
src/sys/dev/random/randomdev_soft.c 1.15.4.1
- -------------------------------------------------------------------------
VII. References
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5162
The latest revision of this advisory is available at
http://security.FreeBSD.org/advisories/FreeBSD-SA-08:11.arc4random.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (FreeBSD)
iEYEARECAAYFAkkq550ACgkQFdaIBMps37K3SwCfcj0iiFxH2tljR1N7/qhXWiW1
N/cAoIjgcsh6sZG/upobud4TVme9QJPf
=SKuK
-----END PGP SIGNATURE-----
From stas at FreeBSD.org Mon Nov 24 09:50:37 2008
From: stas at FreeBSD.org (stas@FreeBSD.org)
Date: Mon Nov 24 09:50:43 2008
Subject: ports/129037: [patch] [vuxml] graphics/imlib2: fix CVE-2008-5187
Message-ID: <200811241750.mAOHoaCK040495@freefall.freebsd.org>
Synopsis: [patch] [vuxml] graphics/imlib2: fix CVE-2008-5187
State-Changed-From-To: open->closed
State-Changed-By: stas
State-Changed-When: Mon Nov 24 17:50:36 UTC 2008
State-Changed-Why:
Committed, with minor changes. Thanks!
http://www.freebsd.org/cgi/query-pr.cgi?pr=129037
From aragon at phat.za.net Mon Nov 24 10:28:08 2008
From: aragon at phat.za.net (Aragon Gouveia)
Date: Mon Nov 24 10:28:14 2008
Subject: [FreeBSD-Announce] FreeBSD Security Advisory
FreeBSD-SA-08:11.arc4random
In-Reply-To: <200811241747.mAOHlDSE034716@freefall.freebsd.org>
References: <200811241747.mAOHlDSE034716@freefall.freebsd.org>
Message-ID: <20081124180859.GA28462@phat.za.net>
| By FreeBSD Security Advisories
| [ 2008-11-24 19:48 +0200 ]
> III. Impact
>
> All security-related kernel subsystems that rely on a quality random
> number generator are subject to a wide range of possible attacks for the
> 300 seconds after boot or until 64k of random data is consumed. The list
> includes:
I suppose this would affect the quality of SSH host keys generated at boot
time by RC?
Thanks,
Aragon
From neldredge at math.ucsd.edu Mon Nov 24 10:18:39 2008
From: neldredge at math.ucsd.edu (Nate Eldredge)
Date: Mon Nov 24 10:32:45 2008
Subject: [FreeBSD-Announce] FreeBSD Security Advisory
FreeBSD-SA-08:11.arc4random
In-Reply-To: <200811241747.mAOHlDSE034716@freefall.freebsd.org>
References: <200811241747.mAOHlDSE034716@freefall.freebsd.org>
Message-ID:
Upon reading this, my first question was whether the weakness applies to
the random numbers supplied by /dev/random. If it does, then userspace has
been getting non-random values, and things like PGP and SSH keys could be
compromised. It might be good for secteam to clarify this, IMHO.
On Mon, 24 Nov 2008, FreeBSD Security Advisories wrote:
> FreeBSD-SA-08.11.arc4random Security Advisory
> The FreeBSD Project
...
--
Nate Eldredge
neldredge@math.ucsd.edu
From william at palfreman.com Mon Nov 24 11:11:05 2008
From: william at palfreman.com (William Palfreman)
Date: Mon Nov 24 11:11:19 2008
Subject: ports/129037: [patch] [vuxml] graphics/imlib2: fix CVE-2008-5187
In-Reply-To: <200811241750.mAOHoaCK040495@freefall.freebsd.org>
References: <200811241750.mAOHoaCK040495@freefall.freebsd.org>
Message-ID: <731a66520811241105h546db4c9yb3d9879f6c8baac3@mail.gmail.com>
2008/11/24 :
> Synopsis: [patch] [vuxml] graphics/imlib2: fix CVE-2008-5187
>
> State-Changed-From-To: open->closed
> State-Changed-By: stas
> State-Changed-When: Mon Nov 24 17:50:36 UTC 2008
> State-Changed-Why:
> Committed, with minor changes. Thanks!
I can see no need for this on the Freebsd-security mailinglist. It
amounts to spam.
From william at palfreman.com Mon Nov 24 11:18:05 2008
From: william at palfreman.com (William Palfreman)
Date: Mon Nov 24 11:18:12 2008
Subject: ports/128999: [vuxml] [patch] update audio/streamripper to
1.64.0, fix CVE-2008-4829
In-Reply-To: <200811230855.mAN8tmXo091500@freefall.freebsd.org>
References: <200811230855.mAN8tmXo091500@freefall.freebsd.org>
Message-ID: <731a66520811241055x62a013at71bc1d08bcc6bda8@mail.gmail.com>
2008/11/23 :
> Synopsis: [vuxml] [patch] update audio/streamripper to 1.64.0, fix CVE-2008-4829
Can we not have these on the freebsd-secuirty list please? I
subscribe to freebsd-security to get security alerts, not to get
emails every time a port is changed.
William Palfreman
From ltning at anduin.net Mon Nov 24 13:37:26 2008
From: ltning at anduin.net (=?ISO-8859-1?Q?Eirik_=D8verby?=)
Date: Mon Nov 24 13:37:34 2008
Subject: Dropping syn+fin replies, but not really?
In-Reply-To: <49299876.4020702@thelostparadise.com>
References:
<49299876.4020702@thelostparadise.com>
Message-ID: <876D0973-A384-4567-8E61-771E96E8A65A@anduin.net>
On Nov 23, 2008, at 18:52, Pieter de Boer wrote:
> Eirik ?verby wrote:
>
>> I have a FreeBSD based firewall (pfsense) and, behind it, a few
>> dozen FreeBSD servers. Now we're required to run external security
>> scans (nessus++) on some of the hosts, and they constantly come
>> back with a "high" or "medium" severity problem: The host replies
>> to TCP packets with SYN+FIN set.
> I'd consider this at most a 'low' severity problem.
Agreed.
>> Problem: Both the firewall (FreeBSD 6.2-based pfSense 1.2) and the
>> host in question (recent FreeBSD 7.2-PRERELEASE) have
>> net.inet.tcp.drop_synfin=1 - I would therefore expect this to be a
>> non-issue.
> Given security tools' (including Nessus') track records of false
> positives, I wouldn't be surprised if this was one of them.
They generate a lot of others, too, mostly due to insufficient or
downright bogus identification of services. Since when did "pound ssl
proxy" equal "aladdin web server"? And since when was it common to run
Apache 2.0.23 for Linux on FreeBSD 7.0? Not to mention all the windows-
specific vulnerabilities I'm supposedly open to.
>> Have I missed something important? Apart from this the hosts and
>> services get away without any serious issues, but the security
>> audit company insists this so-called hole to be closed.
> It's not a hole, but could possibly aid in bypassing filtering rules
> (which is quite unlikely in this day and age). It may be wise to
> find a
> security company that knows how to interpret and verify Nessus output.
>
> If you want to do verification yourself, you could try the following:
> - Run tcpdump on one of the servers and on the firewall
> - Run nmap from an external host using the '--scanflags SYNFIN' flag
> with destination the server.
>
> You can let tcpdump only show specific ports and source/destination
> addresses. It's probably useful to use nmap to scan both ports you
> know
> to be open and in use and ports that are filtered. Using the -p option
> to nmap, you can specify which ports to scan.
>
> Perform the nmap scan and look at the tcpdump output to see how your
> firewall and/or server react.
nmap command:
nmap -PN -sT --scanflags SYNFIN -p anduin.net
where was either 80 (open) or 8585 (closed).
tcpdump command on firewall (which NATs to internal IPs):
tcpdump -i -p -vvv host alge.anart.no and \(port 80 or
port 8585\)
where was the publicly facing interface on the firewall.
Results for port 80:
IP (tos 0x0, ttl 59, id 12785, offset 0, flags [DF], proto: TCP
(6), length: 64) alge.anart.no.40283 > 213.225.74.230.http: S, cksum
0xa720 (correct), 3300467486:3300467486(0) win 16384
IP (tos 0x0, ttl 63, id 10914, offset 0, flags [DF], proto: TCP
(6), length: 60) 213.225.74.230.http > alge.anart.no.40283: S, cksum
0x8ef5 (correct), 347647336:347647336(0) ack 3300467487 win 65535
IP (tos 0x0, ttl 59, id 33877, offset 0, flags [DF], proto: TCP
(6), length: 52) alge.anart.no.40283 > 213.225.74.230.http: ., cksum
0x7dbd (correct), 1:1(0) ack 1 win 16384
IP (tos 0x0, ttl 59, id 31905, offset 0, flags [DF], proto: TCP
(6), length: 40) alge.anart.no.40283 > 213.225.74.230.http: R, cksum
0x7180 (correct), 1:1(0) ack 1 win 0
Results for port 8585:
IP (tos 0x0, ttl 59, id 44156, offset 0, flags [DF], proto: TCP
(6), length: 64) alge.anart.no.1839 > 213.225.74.230.8585: S, cksum
0xf765 (correct), 1324215952:1324215952(0) win 16384
IP (tos 0x0, ttl 63, id 34488, offset 0, flags [DF], proto: TCP
(6), length: 40) 213.225.74.230.8585 > alge.anart.no.1839: R, cksum
0x52ef (correct), 0:0(0) ack 1324215953 win 0
I can't tell what's going on here, except I wouldn't have expected a
reply at all to the second one at least, and maybe not even the first.
However, I don't have enough experience to tell if nmap is doing the
"right thing" here at all.
Thanks,
/Eirik
From william at palfreman.com Mon Nov 24 14:06:58 2008
From: william at palfreman.com (William Palfreman)
Date: Mon Nov 24 14:07:05 2008
Subject: ports/128999: [vuxml] [patch] update audio/streamripper to
1.64.0, fix CVE-2008-4829
In-Reply-To: <492B2242.4080102@vwsoft.com>
References: <200811230855.mAN8tmXo091500@freefall.freebsd.org>
<731a66520811241055x62a013at71bc1d08bcc6bda8@mail.gmail.com>
<492B2242.4080102@vwsoft.com>
Message-ID: <731a66520811241406r6269274ft8a41666efd85560d@mail.gmail.com>
2008/11/24 Volker :
> On 11/24/08 19:55, William Palfreman wrote:
>> 2008/11/23 :
>>> Synopsis: [vuxml] [patch] update audio/streamripper to 1.64.0, fix CVE-2008-4829
>>
>> Can we not have these on the freebsd-secuirty list please? I
>> subscribe to freebsd-security to get security alerts, not to get
>> emails every time a port is changed.
>>
>> William Palfreman
>
> You should better head over to security-advisories@ if you're only
> interested in SA's. Claiming about reading security related issues on a
> security mailing list sounds like fun.
>
> I appreciate Eygenes' work.
That's nice. I am sure it is very useful on the ports mailinglist
where it belongs. I also greatly enjoy the frequent interesting and
informed discussion on the security mailinglist - of which Eirik
Overby's thread recently about syn+fin is one example. But all these
ports announcements, raw patches, garbled html etc. I could really do
without. It is why there are separate lists.
From pieter at thedarkside.nl Mon Nov 24 14:12:11 2008
From: pieter at thedarkside.nl (Pieter de Boer)
Date: Mon Nov 24 14:12:18 2008
Subject: Dropping syn+fin replies, but not really?
In-Reply-To: <876D0973-A384-4567-8E61-771E96E8A65A@anduin.net>
References: <49299876.4020702@thelostparadise.com>
<876D0973-A384-4567-8E61-771E96E8A65A@anduin.net>
Message-ID: <492B26B9.505@thedarkside.nl>
Hi Eirik,
>> Perform the nmap scan and look at the tcpdump output to see how your
>> firewall and/or server react.
>
> nmap command:
> nmap -PN -sT --scanflags SYNFIN -p anduin.net
> where was either 80 (open) or 8585 (closed).
>
> tcpdump command on firewall (which NATs to internal IPs):
> tcpdump -i -p -vvv host alge.anart.no and \(port 80 or port
> 8585\)
> where was the publicly facing interface on the firewall.
>
> Results for port 80:
> IP (tos 0x0, ttl 59, id 12785, offset 0, flags [DF], proto: TCP (6), length: 64) alge.anart.no.40283 > 213.225.74.230.http: S, cksum 0xa720 (correct), 3300467486:3300467486(0) win 16384
> IP (tos 0x0, ttl 63, id 10914, offset 0, flags [DF], proto: TCP (6), length: 60) 213.225.74.230.http > alge.anart.no.40283: S, cksum 0x8ef5 (correct), 347647336:347647336(0) ack 3300467487 win 65535
>
> Results for port 8585:
> IP (tos 0x0, ttl 59, id 44156, offset 0, flags [DF], proto: TCP (6), length: 64) alge.anart.no.1839 > 213.225.74.230.8585: S, cksum 0xf765 (correct), 1324215952:1324215952(0) win 16384
> IP (tos 0x0, ttl 63, id 34488, offset 0, flags [DF], proto: TCP (6), length: 40) 213.225.74.230.8585 > alge.anart.no.1839: R, cksum 0x52ef (correct), 0:0(0) ack 1324215953 win 0
>
> I can't tell what's going on here, except I wouldn't have expected a
> reply at all to the second one at least, and maybe not even the first.
> However, I don't have enough experience to tell if nmap is doing the
> "right thing" here at all.
First of all, this is not a scan with both the SYN and FIN flags set.
This can be seen from the tcpdump output only showing the 'S' flag.
You're using -sT, which makes nmap use connect(), and thus the regular
SYN, SYN/ACK, ACK 3-way-handshake. For a SYN/FIN scan, you'll need root
access. I tested this locally without supplying further TCP scan options
to nmap. Could you retest and make sure you see 'SF' as flags in tcpdump?
Secondly, it would be useful if you'd explain the following: is your
firewall NATting port 8585 also, or is traffic sent to that port handled
by the TCP/IP stack of the firewall itself? Furthermore, it appears the
firewall is not actually filtering traffic to port 8585..
The strictest firewall configuration would be to have everything
filtered except the ports you actually use. Those ports are either
NATted to the back-end system or handled by the firewall itself (in case
you want that functionality). From a security perspective, simply
dropping incoming traffic is better than sending back RST's. In pf this
is the default.
Regards,
Pieter
From stas at FreeBSD.org Mon Nov 24 14:17:18 2008
From: stas at FreeBSD.org (Stanislav Sedov)
Date: Mon Nov 24 14:17:31 2008
Subject: ports/129037: [patch] [vuxml] graphics/imlib2: fix CVE-2008-5187
In-Reply-To: <731a66520811241105h546db4c9yb3d9879f6c8baac3@mail.gmail.com>
References: <200811241750.mAOHoaCK040495@freefall.freebsd.org>
<731a66520811241105h546db4c9yb3d9879f6c8baac3@mail.gmail.com>
Message-ID: <20081125005851.5e528e91.stas@FreeBSD.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Mon, 24 Nov 2008 20:05:26 +0100
"William Palfreman" mentioned:
> 2008/11/24 :
> > Synopsis: [patch] [vuxml] graphics/imlib2: fix CVE-2008-5187
> >
> > State-Changed-From-To: open->closed
> > State-Changed-By: stas
> > State-Changed-When: Mon Nov 24 17:50:36 UTC 2008
> > State-Changed-Why:
> > Committed, with minor changes. Thanks!
>
> I can see no need for this on the Freebsd-security mailinglist. It
> amounts to spam.
This is generated automatically as this PR fixes a security issue.
- --
Stanislav Sedov
ST4096-RIPE
-----BEGIN PGP SIGNATURE-----
iEYEARECAAYFAkkrI5sACgkQK/VZk+smlYEQugCggWHZ+sROzYS9lZLRNpJ652hl
+XcAniWPSlgdZKmyoY0fhtd2OuOCKJ8f
=noDe
-----END PGP SIGNATURE-----
From stas at FreeBSD.org Mon Nov 24 14:17:22 2008
From: stas at FreeBSD.org (Stanislav Sedov)
Date: Mon Nov 24 14:17:32 2008
Subject: [FreeBSD-Announce] FreeBSD Security Advisory
FreeBSD-SA-08:11.arc4random
In-Reply-To:
References: <200811241747.mAOHlDSE034716@freefall.freebsd.org>
Message-ID: <20081125005755.d962ddf0.stas@FreeBSD.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Mon, 24 Nov 2008 10:07:18 -0800 (PST)
Nate Eldredge mentioned:
> Upon reading this, my first question was whether the weakness applies to
> the random numbers supplied by /dev/random. If it does, then userspace has
> been getting non-random values, and things like PGP and SSH keys could be
> compromised. It might be good for secteam to clarify this, IMHO.
>
Userland applications are unaffected ssh keys included. /dev/[u]?random
receives entropy from Yarrow, not from arc4random and feeded with saved
entropy upon boot by /etc/rc.d/initrandom.
Only kernel services that rely on arc4random(9) is vulnerable.
- --
Stanislav Sedov
ST4096-RIPE
-----BEGIN PGP SIGNATURE-----
iEYEARECAAYFAkkrI2cACgkQK/VZk+smlYGvrwCfTEuy+4AIk/b6l6bxRX0tcVs0
PZMAniLO3ltjq5232cErhAtB7u5SJI4J
=UmVN
-----END PGP SIGNATURE-----
From stas at FreeBSD.org Mon Nov 24 14:17:34 2008
From: stas at FreeBSD.org (Stanislav Sedov)
Date: Mon Nov 24 14:17:41 2008
Subject: [FreeBSD-Announce] FreeBSD Security Advisory
FreeBSD-SA-08:11.arc4random
In-Reply-To: <20081124180859.GA28462@phat.za.net>
References: <200811241747.mAOHlDSE034716@freefall.freebsd.org>
<20081124180859.GA28462@phat.za.net>
Message-ID: <20081125005816.8f1993b8.stas@FreeBSD.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Mon, 24 Nov 2008 20:08:59 +0200
Aragon Gouveia mentioned:
> | By FreeBSD Security Advisories
> | [ 2008-11-24 19:48 +0200 ]
> > III. Impact
> >
> > All security-related kernel subsystems that rely on a quality random
> > number generator are subject to a wide range of possible attacks for the
> > 300 seconds after boot or until 64k of random data is consumed. The list
> > includes:
>
> I suppose this would affect the quality of SSH host keys generated at boot
> time by RC?
>
Nope, userland is unaffected.
- --
Stanislav Sedov
ST4096-RIPE
-----BEGIN PGP SIGNATURE-----
iEUEARECAAYFAkkrI3gACgkQK/VZk+smlYFwWQCXSwYxHbUizxmriBT3pO1Ei8W7
GACff74X/J3b4c01zRkXmsYxE981hwk=
=v+Xl
-----END PGP SIGNATURE-----
From volker at vwsoft.com Mon Nov 24 14:19:03 2008
From: volker at vwsoft.com (Volker)
Date: Mon Nov 24 14:19:11 2008
Subject: ports/128999: [vuxml] [patch] update audio/streamripper
to 1.64.0, fix CVE-2008-4829
In-Reply-To: <731a66520811241055x62a013at71bc1d08bcc6bda8@mail.gmail.com>
References: <200811230855.mAN8tmXo091500@freefall.freebsd.org>
<731a66520811241055x62a013at71bc1d08bcc6bda8@mail.gmail.com>
Message-ID: <492B2242.4080102@vwsoft.com>
On 11/24/08 19:55, William Palfreman wrote:
> 2008/11/23 :
>> Synopsis: [vuxml] [patch] update audio/streamripper to 1.64.0, fix CVE-2008-4829
>
> Can we not have these on the freebsd-secuirty list please? I
> subscribe to freebsd-security to get security alerts, not to get
> emails every time a port is changed.
>
> William Palfreman
You should better head over to security-advisories@ if you're only
interested in SA's. Claiming about reading security related issues on a
security mailing list sounds like fun.
I appreciate Eygenes' work.
Volker
From davidski at deadheaven.com Mon Nov 24 14:35:43 2008
From: davidski at deadheaven.com (David F. Severski)
Date: Mon Nov 24 14:36:19 2008
Subject: ports/128999: [vuxml] [patch] update audio/streamripper to
1.64.0, fix CVE-2008-4829
In-Reply-To: <731a66520811241406r6269274ft8a41666efd85560d@mail.gmail.com>
References: <200811230855.mAN8tmXo091500@freefall.freebsd.org>
<731a66520811241055x62a013at71bc1d08bcc6bda8@mail.gmail.com>
<492B2242.4080102@vwsoft.com>
<731a66520811241406r6269274ft8a41666efd85560d@mail.gmail.com>
Message-ID: <20081124222029.GM85200@geoff.deadheaven.com>
On Mon, Nov 24, 2008 at 11:06:56PM +0100, William Palfreman wrote:
> That's nice. I am sure it is very useful on the ports mailinglist
> where it belongs. I also greatly enjoy the frequent interesting and
> informed discussion on the security mailinglist - of which Eirik
> Overby's thread recently about syn+fin is one example. But all these
> ports announcements, raw patches, garbled html etc. I could really do
> without. It is why there are separate lists.
Was there a discussion or even an announcement indicating that the
security-related port commit messages would be sent to freebsd-security?
This seems to have started just this month. Like William, I also find the
explosion of commit messages and bug tracking minutia detracts from the
low volume and high value of the freebsd-security list. The list
description on mailman indicates the intent of the list is to be a
'high-signal, low-noise discussion of issues affecting the security of
FreeBSD.' Including every single obliquely security related port commit
seems counter to this intention.
I'd very much like to see a separate list for the automated port postings,
leaving this list to it's historical usage.
David
From ltning at anduin.net Mon Nov 24 14:40:45 2008
From: ltning at anduin.net (=?ISO-8859-1?Q?Eirik_=D8verby?=)
Date: Mon Nov 24 14:40:52 2008
Subject: Dropping syn+fin replies, but not really?
In-Reply-To: <492B26B9.505@thedarkside.nl>
References: <49299876.4020702@thelostparadise.com>
<876D0973-A384-4567-8E61-771E96E8A65A@anduin.net>
<492B26B9.505@thedarkside.nl>
Message-ID: <0A92AEEC-5AF2-4DB7-9ACD-855731E168C6@anduin.net>
On Nov 24, 2008, at 23:12, Pieter de Boer wrote:
> Hi Eirik,
>
>>> Perform the nmap scan and look at the tcpdump output to see how your
>>> firewall and/or server react.
>> nmap command:
>> nmap -PN -sT --scanflags SYNFIN -p anduin.net
>> where was either 80 (open) or 8585 (closed).
>> tcpdump command on firewall (which NATs to internal IPs):
>> tcpdump -i -p -vvv host alge.anart.no and \(port 80 or
>> port 8585\)
>> where was the publicly facing interface on the firewall.
>> Results for port 80:
>> IP (tos 0x0, ttl 59, id 12785, offset 0, flags [DF], proto: TCP
>> (6), length: 64) alge.anart.no.40283 > 213.225.74.230.http: S,
>> cksum 0xa720 (correct), 3300467486:3300467486(0) win 16384 > 1460,nop,nop,sackOK,nop,wscale 0,nop,nop,timestamp 2747936488 0>
>> IP (tos 0x0, ttl 63, id 10914, offset 0, flags [DF], proto: TCP
>> (6), length: 60) 213.225.74.230.http > alge.anart.no.40283: S,
>> cksum 0x8ef5 (correct), 347647336:347647336(0) ack 3300467487 win
>> 65535
>> Results for port 8585:
>> IP (tos 0x0, ttl 59, id 44156, offset 0, flags [DF], proto: TCP
>> (6), length: 64) alge.anart.no.1839 > 213.225.74.230.8585: S, cksum
>> 0xf765 (correct), 1324215952:1324215952(0) win 16384 > 1460,nop,nop,sackOK,nop,wscale 0,nop,nop,timestamp 4070158112 0>
>> IP (tos 0x0, ttl 63, id 34488, offset 0, flags [DF], proto: TCP
>> (6), length: 40) 213.225.74.230.8585 > alge.anart.no.1839: R, cksum
>> 0x52ef (correct), 0:0(0) ack 1324215953 win 0
>> I can't tell what's going on here, except I wouldn't have expected
>> a reply at all to the second one at least, and maybe not even the
>> first. However, I don't have enough experience to tell if nmap is
>> doing the "right thing" here at all.
>
> First of all, this is not a scan with both the SYN and FIN flags
> set. This can be seen from the tcpdump output only showing the 'S'
> flag. You're using -sT, which makes nmap use connect(), and thus the
> regular SYN, SYN/ACK, ACK 3-way-handshake. For a SYN/FIN scan,
> you'll need root access. I tested this locally without supplying
> further TCP scan options to nmap. Could you retest and make sure you
> see 'SF' as flags in tcpdump?
I don't. With
nmap --scanflags SYNFIN -p
as root, I got, from what I can tell, exactly the same. May be this is
filtered on the way out, so I need to find an unhampered box to try
from? I could simply try crossing vlans through the firewall, I guess.
> Secondly, it would be useful if you'd explain the following: is your
> firewall NATting port 8585 also, or is traffic sent to that port
> handled by the TCP/IP stack of the firewall itself? Furthermore, it
> appears the firewall is not actually filtering traffic to port 8585..
This particular machine is behind 1:1 NATing. I usually do NAT+fwrules
for needed ports only, but even in those cases I get the (false?) syn
+fin alerts from (in this case) securityspace.com.
> The strictest firewall configuration would be to have everything
> filtered except the ports you actually use. Those ports are either
> NATted to the back-end system or handled by the firewall itself (in
> case you want that functionality). From a security perspective,
> simply dropping incoming traffic is better than sending back RST's.
> In pf this is the default.
That is correct, however in this case I do 1:1 and no pf on the target
host (it is in a DMZ). I ran the scan on this system out of curiosity
only, however as stated above this problem is far from unique to this
particular system.
Thanks for your input, i'll keep trying to reproduce this..
/Eirik
From freebsd-security at dfmm.org Mon Nov 24 14:54:16 2008
From: freebsd-security at dfmm.org (Jason Stone)
Date: Mon Nov 24 14:54:23 2008
Subject: ports/128999: [vuxml] [patch] update audio/streamripper to
1.64.0, fix CVE-2008-4829
In-Reply-To: <731a66520811241406r6269274ft8a41666efd85560d@mail.gmail.com>
References: <200811230855.mAN8tmXo091500@freefall.freebsd.org>
<731a66520811241055x62a013at71bc1d08bcc6bda8@mail.gmail.com>
<492B2242.4080102@vwsoft.com>
<731a66520811241406r6269274ft8a41666efd85560d@mail.gmail.com>
Message-ID:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
>> You should better head over to security-advisories@ if you're only
>> interested in SA's. Claiming about reading security related issues on a
>> security mailing list sounds like fun.
>>
>> I appreciate Eygenes' work.
I also appreciate this work, but I agree that I don't think it's
appropriate for freebsd-security@. It's much too noisy, and makes it
harder to see real discussion in amongst the noise.
If people really would like to see these kind of notifications (i.e.,
security-related PRs for ports) in mailing-list format, I think that a
separate mailing list would be appropriate (e.g.,
freebsd-security-ports@).
Thanks as always to the security team for their fine work.
-Jason
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (FreeBSD)
Comment: See https://private.idealab.com/public/jason/jason.gpg
iD8DBQFJKypWswXMWWtptckRAnxBAJ4lbTt4DzBwrfJQ9BMwUlNqY/b23gCfSN6u
XUSM49KMxTBvBBDc6T12EOA=
=98ll
-----END PGP SIGNATURE-----
From fbsd06 at mlists.homeunix.com Mon Nov 24 15:30:46 2008
From: fbsd06 at mlists.homeunix.com (Robert Woolley)
Date: Mon Nov 24 15:30:53 2008
Subject: [FreeBSD-Announce] FreeBSD Security Advisory
FreeBSD-SA-08:11.arc4random
In-Reply-To:
References: <200811241747.mAOHlDSE034716@freefall.freebsd.org>
Message-ID: <20081124231435.326fadc4@gumby.homeunix.com>
On Mon, 24 Nov 2008 10:07:18 -0800 (PST)
Nate Eldredge wrote:
> Upon reading this, my first question was whether the weakness applies
> to the random numbers supplied by /dev/random. If it does, then
> userspace has been getting non-random values, and things like PGP and
> SSH keys could be compromised. It might be good for secteam to
> clarify this, IMHO.
I'm not from secteam, but I did submit the problem and suggest the
solution.
The primary problem is that the kernel version of arc4random is seeded
from yarrow before yarrow itself is seeded. This does not affect
/dev/random or userland arc4random, just the things mentioned in
the advisory.
However, there is a second problem that is fixed by the patch, but
not documented in the advisory. Closing a write to /dev/random causes a
yarrow reseed, but previously didn't flush the entropy queue first. The
first 4kB of low-grade entropy that's fed into /dev/random before the
entropy file causes the queue to saturate, leaving no space for the
entropy file, which is tail-dropped. And without a flush any entropy in
the queues isn't processed into the yarrow key until another reseed
occurs, at which point it's redundant anyway.
In short, the primary entropy file didn't previously do anything useful.
Whether that's actually a problem isn't clear to me. On my desktop
machine yarrow reseeds by itself before the entropy file is used, due
to disk activity. There may however be some platforms where the entropy
file is really needed, and /dev/random itself may have been a bit
insecure until the stage in the boot process where /var is mounted and
the secondary entropy files in /var/db/entropy/ are used.
PGP and SSH keys are generated late in the boot process, or after boot,
usually on machines with plenty of entropy, so there shouldn't be an
issue there.
From kitchetech at gmail.com Mon Nov 24 14:53:50 2008
From: kitchetech at gmail.com (matt donovan)
Date: Mon Nov 24 16:20:28 2008
Subject: ports/128999: [vuxml] [patch] update audio/streamripper to
1.64.0, fix CVE-2008-4829
In-Reply-To: <731a66520811241406r6269274ft8a41666efd85560d@mail.gmail.com>
References: <200811230855.mAN8tmXo091500@freefall.freebsd.org>
<731a66520811241055x62a013at71bc1d08bcc6bda8@mail.gmail.com>
<492B2242.4080102@vwsoft.com>
<731a66520811241406r6269274ft8a41666efd85560d@mail.gmail.com>
Message-ID: <28283d910811241433w4a20ffe8mca58bc98d55b3ac3@mail.gmail.com>
On Mon, Nov 24, 2008 at 5:06 PM, William Palfreman wrote:
> 2008/11/24 Volker :
> > On 11/24/08 19:55, William Palfreman wrote:
> >> 2008/11/23 :
> >>> Synopsis: [vuxml] [patch] update audio/streamripper to 1.64.0, fix
> CVE-2008-4829
> >>
> >> Can we not have these on the freebsd-secuirty list please? I
> >> subscribe to freebsd-security to get security alerts, not to get
> >> emails every time a port is changed.
> >>
> >> William Palfreman
> >
> > You should better head over to security-advisories@ if you're only
> > interested in SA's. Claiming about reading security related issues on a
> > security mailing list sounds like fun.
> >
> > I appreciate Eygenes' work.
>
> That's nice. I am sure it is very useful on the ports mailinglist
> where it belongs. I also greatly enjoy the frequent interesting and
> informed discussion on the security mailinglist - of which Eirik
> Overby's thread recently about syn+fin is one example. But all these
> ports announcements, raw patches, garbled html etc. I could really do
> without. It is why there are separate lists.
> _______________________________________________
> freebsd-ports@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org"
>
you do know that the email your complaining about is about a security update
correct? if you don't like it then you really need to use
security-advisories instead of being subscribed to this one
From smithi at nimnet.asn.au Mon Nov 24 21:51:33 2008
From: smithi at nimnet.asn.au (Ian Smith)
Date: Mon Nov 24 21:51:41 2008
Subject: ports/128999: [vuxml] [patch] update audio/streamripper to
1.64.0, fix CVE-2008-4829
In-Reply-To: <20081124222029.GM85200@geoff.deadheaven.com>
References: <200811230855.mAN8tmXo091500@freefall.freebsd.org>
<731a66520811241055x62a013at71bc1d08bcc6bda8@mail.gmail.com>
<492B2242.4080102@vwsoft.com>
<731a66520811241406r6269274ft8a41666efd85560d@mail.gmail.com>
<20081124222029.GM85200@geoff.deadheaven.com>
Message-ID: <20081125153335.Q43853@sola.nimnet.asn.au>
On Mon, 24 Nov 2008, David F. Severski wrote:
> On Mon, Nov 24, 2008 at 11:06:56PM +0100, William Palfreman wrote:
> > That's nice. I am sure it is very useful on the ports mailinglist
> > where it belongs. I also greatly enjoy the frequent interesting and
> > informed discussion on the security mailinglist - of which Eirik
> > Overby's thread recently about syn+fin is one example. But all these
> > ports announcements, raw patches, garbled html etc. I could really do
> > without. It is why there are separate lists.
>
> Was there a discussion or even an announcement indicating that the
> security-related port commit messages would be sent to freebsd-security?
Not that I could find. The other day I reviewed the last three months'
archives looking for any notice I'd missed. These ports security issues
and patches postings began on Nov 8; I've resisted commenting until now.
> This seems to have started just this month. Like William, I also find the
> explosion of commit messages and bug tracking minutia detracts from the
> low volume and high value of the freebsd-security list. The list
> description on mailman indicates the intent of the list is to be a
> 'high-signal, low-noise discussion of issues affecting the security of
> FreeBSD.' Including every single obliquely security related port commit
> seems counter to this intention.
>
> I'd very much like to see a separate list for the automated port postings,
> leaving this list to it's historical usage.
I'm also finding these to be swamping S/N (as are these posts, I know!)
and no, switching to security-advisories@ wouldn't cut it for me, for
the same reasons William mentions above.
We're heading towards 20,000 ports these days, and while I appreciate
and rely on the vuxml database and portaudit for vulns and updates for
those ports I use, and am glad to see such active work going on, I'm
feeling the separation of base system (including contrib) from ports
remains important - especially in the security context.
My 2c (now scarcely U$1.3c),
Ian
From rea-fbsd at codelabs.ru Mon Nov 24 23:08:24 2008
From: rea-fbsd at codelabs.ru (Eygene Ryabinkin)
Date: Mon Nov 24 23:08:40 2008
Subject: PR followups in the freebsd-security list [WAS: ports/129037:
[patch] [vuxml] graphics/imlib2: fix CVE-2008-5187]
In-Reply-To: <731a66520811241105h546db4c9yb3d9879f6c8baac3@mail.gmail.com>
References: <200811241750.mAOHoaCK040495@freefall.freebsd.org>
<731a66520811241105h546db4c9yb3d9879f6c8baac3@mail.gmail.com>
Message-ID:
William, everyone, good day.
Mon, Nov 24, 2008 at 08:05:26PM +0100, William Palfreman wrote:
> 2008/11/24 :
> > Synopsis: [patch] [vuxml] graphics/imlib2: fix CVE-2008-5187
> >
> > State-Changed-From-To: open->closed
> > State-Changed-By: stas
> > State-Changed-When: Mon Nov 24 17:50:36 UTC 2008
> > State-Changed-Why:
> > Committed, with minor changes. Thanks!
>
> I can see no need for this on the Freebsd-security mailinglist. It
> amounts to spam.
Sorry for this. I used to put freebsd-security@ to the X-GNATS-Notify
field of the PR, so followups were slipping to this list.
Since the very last Sunday (or Saturday, don't remember well ;)), I am
putting freebsd-security@freebsd.org to the CC field of the original PR.
Thus, only initial posting will go into the list. I hope that such
approach will be better for the list and its subscribers. If this still
won't be a satisfying decision, I can completely drop freebsd-security@
from the PR recipients, but in this case I could miss some important
feedback from the community and I want to avoid this, if it will be
possible.
Once again, sorry for the noise. Old PR's will still produce some
amount of follow-ups, but the new ones shouldn't do it anymore.
While I am here: thanks for the appreciation of my work that was
expressed by the people in the list ;))
Thanks for your patience!
--
Eygene
_ ___ _.--. #
\`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, / # while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / # -- FreeBSD Developers handbook
{_.-``-' {_/ #
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-security/attachments/20081125/42b9e1f7/attachment.pgp
From m.seaman at infracaninophile.co.uk Tue Nov 25 03:52:25 2008
From: m.seaman at infracaninophile.co.uk (Matthew Seaman)
Date: Tue Nov 25 03:52:32 2008
Subject: ports/128999: [vuxml] [patch] update audio/streamripper to
1.64.0, fix CVE-2008-4829
In-Reply-To:
References: <200811230855.mAN8tmXo091500@freefall.freebsd.org> <731a66520811241055x62a013at71bc1d08bcc6bda8@mail.gmail.com> <492B2242.4080102@vwsoft.com> <731a66520811241406r6269274ft8a41666efd85560d@mail.gmail.com>
Message-ID: <492BE6CE.4040809@infracaninophile.co.uk>
Jason Stone wrote:
> If people really would like to see these kind of notifications (i.e.,
> security-related PRs for ports) in mailing-list format, I think that a
> separate mailing list would be appropriate (e.g.,
> freebsd-security-ports@).
There's already a freebsd-vuxml@ list which hasn't seen any traffic
for a long time...
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
Kent, CT11 9PW
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 258 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-security/attachments/20081125/57ddbb0c/signature.pgp
From jesper at nohack.se Mon Nov 24 19:05:09 2008
From: jesper at nohack.se (Jesper Wallin)
Date: Tue Nov 25 04:18:10 2008
Subject: Dropping syn+fin replies, but not really?
In-Reply-To: <+ug4ae9RHVVTC7ztvaDEPTyd/iQ@iXA9ZWPrtc2I2BMzBXoToMd7YdQ>
References:
<+ug4ae9RHVVTC7ztvaDEPTyd/iQ@iXA9ZWPrtc2I2BMzBXoToMd7YdQ>
Message-ID: <20081125024516.GA81845@zero.nohack.se>
* Eygene Ryabinkin [2008-11-23 23:43:03 +0300]:
> Eirik, good day.
>
> Sun, Nov 23, 2008 at 05:03:15PM +0100, Eirik ?verby wrote:
> > I have a FreeBSD based firewall (pfsense) and, behind it, a few dozen
> > FreeBSD servers. Now we're required to run external security scans
> > (nessus++) on some of the hosts, and they constantly come back with a
> > "high" or "medium" severity problem: The host replies to TCP packets
> > with SYN+FIN set.
> >
> > Problem: Both the firewall (FreeBSD 6.2-based pfSense 1.2) and the
> > host in question (recent FreeBSD 7.2-PRERELEASE) have
> > net.inet.tcp.drop_synfin=1 - I would therefore expect this to be a non-
> > issue.
>
> First of all, (if I am correct) your firewall's setting for drop_synfin
> isn't relevant for the packets that are traversing the firewall: TCP
> input layer drops these and firewall isn't using this layer.
>
> The easy way to identify if there are replies to SYN+FIN is to spawn
> tcpdump on the firewall and see what's going on. It may be well so that
> the some sort of scrubbing/modulation is done on the firewall, so when
> firewall notices that the SYN + FIN is blackholed, it generates RST by
> itself or just blocks SYN + FIN by itself, but sends RST. I am making
> guesses here, because I can't test it just now and I have no idea about
> your setup.
>
> If I remember correctly, pf is used on the pfSense, so you can easily
> block SYN + FIN on the ingress port(s):
> -----
> block in quick on $ingress proto tcp from any to \
> flags SF/ASF
> -----
Might worth pointing out that if pfSense indeed uses pf, and it's setup to use the "scrub" option, a packet with SYN/FIN will simply have the FIN bit removed and the packet is delivered as a normal SYN packet. This will probably cause most pen-testing software to believe that the target host accepts packets with SYN/FIN set.
Come to think of it, I wrote a similar post about this a few years ago:
http://lists.freebsd.org/pipermail/freebsd-security/2005-July/003010.html
Though, don't use that "patch" unless you know what you're doing, especially since it's written ages ago and the source has probably been modified both once or twice by now. :-)
Regards,
Jesper
> --
> Eygene
> _ ___ _.--. #
> \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard
> / ' ` , __.--' # to read the on-line manual
> )/' _/ \ `-_, / # while single-stepping the kernel.
> `-'" `"\_ ,_.-;_.-\_ ', fsc/as #
> _.-'_./ {_.' ; / # -- FreeBSD Developers handbook
> {_.-``-' {_/ #
From rea-fbsd at codelabs.ru Tue Nov 25 04:49:36 2008
From: rea-fbsd at codelabs.ru (Eygene Ryabinkin)
Date: Tue Nov 25 04:49:43 2008
Subject: ports/128999: [vuxml] [patch] update audio/streamripper to
1.64.0, fix CVE-2008-4829
In-Reply-To: <492BE6CE.4040809@infracaninophile.co.uk>
References: <200811230855.mAN8tmXo091500@freefall.freebsd.org>
<731a66520811241055x62a013at71bc1d08bcc6bda8@mail.gmail.com>
<492B2242.4080102@vwsoft.com>
<731a66520811241406r6269274ft8a41666efd85560d@mail.gmail.com>
<492BE6CE.4040809@infracaninophile.co.uk>
Message-ID:
Matthew, good day.
Tue, Nov 25, 2008 at 11:51:42AM +0000, Matthew Seaman wrote:
> Jason Stone wrote:
>
> > If people really would like to see these kind of notifications (i.e.,
> > security-related PRs for ports) in mailing-list format, I think that a
> > separate mailing list would be appropriate (e.g.,
> > freebsd-security-ports@).
>
> There's already a freebsd-vuxml@ list which hasn't seen any traffic
> for a long time...
Wow, thanks for information! So, I think I'll now CC my PRs to that
list. But the question is: should I leave freebsd-security@ in the CC
or people prefer not to see them here. Posting PRs to the dead list
isn't a very good idea, you know, but () may be the list
will be resurrected with my postings.
Since freebsd-security is said to be "high-signal, low-noise
discussion", then I'll refrain from CC'ing it for now, but if there will
be any interest -- I can add CC back.
Thanks!
--
Eygene
_ ___ _.--. #
\`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, / # while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / # -- FreeBSD Developers handbook
{_.-``-' {_/ #
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-security/attachments/20081125/61094187/attachment.pgp
From smithi at nimnet.asn.au Tue Nov 25 04:52:40 2008
From: smithi at nimnet.asn.au (Ian Smith)
Date: Tue Nov 25 04:52:48 2008
Subject: Dropping syn+fin replies, but not really?
In-Reply-To: <0A92AEEC-5AF2-4DB7-9ACD-855731E168C6@anduin.net>
References:
<49299876.4020702@thelostparadise.com>
<876D0973-A384-4567-8E61-771E96E8A65A@anduin.net>
<492B26B9.505@thedarkside.nl>
<0A92AEEC-5AF2-4DB7-9ACD-855731E168C6@anduin.net>
Message-ID: <20081125232938.C43853@sola.nimnet.asn.au>
On Mon, 24 Nov 2008, Eirik ?verby wrote:
> On Nov 24, 2008, at 23:12, Pieter de Boer wrote:
[..]
> > > Results for port 8585:
> > > IP (tos 0x0, ttl 59, id 44156, offset 0, flags [DF], proto: TCP (6),
> > > length: 64) alge.anart.no.1839 > 213.225.74.230.8585: S, cksum 0xf765
> > > (correct), 1324215952:1324215952(0) win 16384 > > 1460,nop,nop,sackOK,nop,wscale 0,nop,nop,timestamp 4070158112 0>
> > > IP (tos 0x0, ttl 63, id 34488, offset 0, flags [DF], proto: TCP (6),
> > > length: 40) 213.225.74.230.8585 > alge.anart.no.1839: R, cksum 0x52ef
> > > (correct), 0:0(0) ack 1324215953 win 0
> > > I can't tell what's going on here, except I wouldn't have expected a
> > > reply at all to the second one at least, and maybe not even the first.
> > > However, I don't have enough experience to tell if nmap is doing the
> > > "right thing" here at all.
[..]
> > The strictest firewall configuration would be to have everything filtered
> > except the ports you actually use. Those ports are either NATted to the
> > back-end system or handled by the firewall itself (in case you want that
> > functionality). From a security perspective, simply dropping incoming
> > traffic is better than sending back RST's. In pf this is the default.
>
> That is correct, however in this case I do 1:1 and no pf on the target host
> (it is in a DMZ). I ran the scan on this system out of curiosity only,
> however as stated above this problem is far from unique to this particular
> system.
>
> Thanks for your input, i'll keep trying to reproduce this..
Perhaps off to the side, but I wonder if net.inet.tcp.blackhole may be
relevant? Here tcpdump was showing RSTs back to attempted connections
to unused ports, despite these being dropped on ingress by the firewall,
which I thought was unnecessarily informative :)
# net.inet.tcp.blackhole: Do not send RST when dropping refused connections
net.inet.tcp.blackhole=1
fixed that here. Caveats: that's on a 5.5-STABLE box using ipfw to drop
such connections. I'd been surprised to see those RSTs too ..
cheers, Ian
From wxs at FreeBSD.org Tue Nov 25 06:43:26 2008
From: wxs at FreeBSD.org (Wesley Shields)
Date: Tue Nov 25 06:43:33 2008
Subject: ports/128999: [vuxml] [patch] update audio/streamripper to
1.64.0, fix CVE-2008-4829
In-Reply-To:
References: <200811230855.mAN8tmXo091500@freefall.freebsd.org>
<731a66520811241055x62a013at71bc1d08bcc6bda8@mail.gmail.com>
<492B2242.4080102@vwsoft.com>
<731a66520811241406r6269274ft8a41666efd85560d@mail.gmail.com>
<492BE6CE.4040809@infracaninophile.co.uk>
Message-ID: <20081125142601.GA73229@atarininja.org>
On Tue, Nov 25, 2008 at 03:49:33PM +0300, Eygene Ryabinkin wrote:
> Matthew, good day.
>
> Tue, Nov 25, 2008 at 11:51:42AM +0000, Matthew Seaman wrote:
> > Jason Stone wrote:
> >
> > > If people really would like to see these kind of notifications (i.e.,
> > > security-related PRs for ports) in mailing-list format, I think that a
> > > separate mailing list would be appropriate (e.g.,
> > > freebsd-security-ports@).
> >
> > There's already a freebsd-vuxml@ list which hasn't seen any traffic
> > for a long time...
>
> Wow, thanks for information! So, I think I'll now CC my PRs to that
> list. But the question is: should I leave freebsd-security@ in the CC
> or people prefer not to see them here. Posting PRs to the dead list
> isn't a very good idea, you know, but () may be the list
> will be resurrected with my postings.
The vuxml list is a much better place for this, based upon the
description of the list:
"entries in the FreeBSD VuXML document (new submissions, modifications,
style, and so on)"
> Since freebsd-security is said to be "high-signal, low-noise
> discussion", then I'll refrain from CC'ing it for now, but if there will
> be any interest -- I can add CC back.
While I echo earlier statements about the appreciation for your work I
do believe that the vuxml list is a more appropriate place to CC your
submissions, if you feel the need to CC something. As someone who
actively looks at incoming PRs I don't think you need to CC anything,
but if you have to then the vuxml list is a better fit than this.
-- WXS
From rea-fbsd at codelabs.ru Fri Nov 28 03:43:19 2008
From: rea-fbsd at codelabs.ru (Eygene Ryabinkin)
Date: Fri Nov 28 03:43:26 2008
Subject: ports/129001: [vuxml] [patch] print/cups-base: fix
NULL-pointer dereference
In-Reply-To: <200811280812.mAS8Cl1I082793@freefall.freebsd.org>
References: <200811280812.mAS8Cl1I082793@freefall.freebsd.org>
Message-ID: <9LJUyqikTfkwbhp0EZ7XUmqhGu0@qm7gbYKMPO53E/nl+D5eD8YyL1A>
Dirk, good day.
Fri, Nov 28, 2008 at 09:12:47AM +0100, dinoex@FreeBSD.org wrote:
> Synopsis: [vuxml] [patch] print/cups-base: fix NULL-pointer dereference
>
> State-Changed-From-To: feedback->closed
> State-Changed-By: dinoex
> State-Changed-When: Fri Nov 28 09:11:46 CET 2008
> State-Changed-Why:
> The patch was mangled again.
In the interface that is provided by query-pr.cgi -- yes. But I had
sent it to you directly. Was it mangled too?
> committed, thanks.
Thank you. Again, what about VuXML entry?
--
Eygene
_ ___ _.--. #
\`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, / # while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / # -- FreeBSD Developers handbook
{_.-``-' {_/ #
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-security/attachments/20081128/85abd23c/attachment.pgp
From dinoex at FreeBSD.org Fri Nov 28 00:12:48 2008
From: dinoex at FreeBSD.org (dinoex@FreeBSD.org)
Date: Fri Nov 28 04:27:09 2008
Subject: ports/129001: [vuxml] [patch] print/cups-base: fix NULL-pointer
dereference
Message-ID: <200811280812.mAS8Cl1I082793@freefall.freebsd.org>
Synopsis: [vuxml] [patch] print/cups-base: fix NULL-pointer dereference
State-Changed-From-To: feedback->closed
State-Changed-By: dinoex
State-Changed-When: Fri Nov 28 09:11:46 CET 2008
State-Changed-Why:
The patch was mangled again.
committed, thanks.
http://www.freebsd.org/cgi/query-pr.cgi?pr=129001
From mark at foster.cc Sat Nov 29 20:10:37 2008
From: mark at foster.cc (Mark D. Foster)
Date: Sat Nov 29 20:10:44 2008
Subject: ports/128999: [vuxml] [patch] update audio/streamripper
to 1.64.0, fix CVE-2008-4829
In-Reply-To: <20081125142601.GA73229@atarininja.org>
References: <200811230855.mAN8tmXo091500@freefall.freebsd.org> <731a66520811241055x62a013at71bc1d08bcc6bda8@mail.gmail.com> <492B2242.4080102@vwsoft.com> <731a66520811241406r6269274ft8a41666efd85560d@mail.gmail.com> <492BE6CE.4040809@infracaninophile.co.uk>
<20081125142601.GA73229@atarininja.org>
Message-ID: <49320E7B.40206@foster.cc>
Wesley Shields wrote:
> On Tue, Nov 25, 2008 at 03:49:33PM +0300, Eygene Ryabinkin wrote:
>
>> Matthew, good day.
>>
>> Tue, Nov 25, 2008 at 11:51:42AM +0000, Matthew Seaman wrote:
>>
>>> Jason Stone wrote:
>>>
>>>
>>>> If people really would like to see these kind of notifications (i.e.,
>>>> security-related PRs for ports) in mailing-list format, I think that a
>>>> separate mailing list would be appropriate (e.g.,
>>>> freebsd-security-ports@).
>>>>
>>> There's already a freebsd-vuxml@ list which hasn't seen any traffic
>>> for a long time...
>>>
>> Wow, thanks for information! So, I think I'll now CC my PRs to that
>> list. But the question is: should I leave freebsd-security@ in the CC
>> or people prefer not to see them here. Posting PRs to the dead list
>> isn't a very good idea, you know, but () may be the list
>> will be resurrected with my postings.
>>
[snip]
It would also be helpful also to (re)clarify this statement found @
http://www.vuxml.org/freebsd/
Please report security issues to the FreeBSD Security Team at
--
Said one park ranger, 'There is considerable overlap between the
intelligence of the smartest bears and the dumbest tourists.'
Mark D. Foster, CISSP http://mark.foster.cc/