Bug#482079: libghc6-pcre-light-dev fails to install: workaround

[Recai Oktaş]

* Luca Falavigna [2008-07-12 21:05:12+0200]
> Attached is a workaround for this issue:
> Thank you.

Many thanks for the patch which (hopefully) resolved this issue that I
haven't been able to deal with.  I'm going to make a new upload.

-- 
roktas



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#472279: elog: should this package be removed?

[Recai Oktaş]

[Also CC'ing to Nico... I've just noticed the response at #464902.]

* Raphael Geissert [2008-03-22 20:37:35-0600]
> Source: elog
> Version: 2.6.3+r1764-1
> Severity: serious
> User: [EMAIL PROTECTED]
> Usertags: proposed-removal
> 
> Hi,
> 
> While reviewing some packages, your package came up as a possible
> candidate for removal from Debian, because:
> 
>  * It has a RC bug
>  * It has a history of security issues
>  * last maintainer upload was on 2006
>  * It has almost no users
>  * It is not part of etch and, as for now, won't be part of lenny
>  * There's a new upstream release that is said to address the RC bug
> 
> If you think that it should be orphaned instead of being removed from
> Debian, please reply to this bug and tell so.

Sorry for the late response!  I had already filed a bug report to orphan
elog: #464902.  However removing this package from the archives is also
fine with me, unless someone willing to maintain it comes up.

Best regards,

-- 
roktas


signature.asc
Description: Digital signature

Bug#445235: libghc6-pandoc-dev: the package fails to install

[Recai Oktaş]

tags 445235 + fixed-upstream
thanks

-- 
roktas



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#392016: elog in stable is also vulnerable

[Recai Oktaş]

* Ulf Harnhammar [2006-11-08 23:14:16+0100]
> I've just verified that elog in stable is vulnerable to
> all issues mentioned in bug #392016.

Thank you very much for looking into this!  I've got another report
attached below.  I'll look into this problem also and will keep this bug
report open as I think elog should not enter to Etch due to all potential
security issues which increase the work-load on our security team during
the stable release cycle.

-->8---
FYI

Hi,
We are working with Mr. Stefan Ritt on this issue and waiting for the fix.

Thanks,
OS2A


Forwarded Conversation
Subject: ELOG Web Logbook Remote Denial of Service Vulnerability


 From: OS2A BTO <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Date: Wed, Nov 8, 2006 at 6:12 PM
Attachments: os2a_1008.txt

Hi,
We recently came across a Denial of Service vulnerability in ELOG's
elogd server which allows attackers to crash the service, thereby preventing
legitimate access.

Attached is our security advisory which describes the vulnerability in detail.

Please let us know the time you might require to fix this issue.
And also let us know if you have any questions.

A quick and positive response from your side would be highly appreciated.

Thanks,
OS2A Team.



 From: Stefan Ritt <[EMAIL PROTECTED]>
To: OS2A BTO <[EMAIL PROTECTED]>
Date: Wed, Nov 8, 2006 at 6:31 PM

Dear OS2A team,

thank you for reporting this vulnerability and for the detailed
analysis, I really appreciate. I fixed this problem and just released
version 2.6.2-7 (SVN revision 1746).

Best regards,

   Stefan Ritt

--
Dr. Stefan Ritt   Phone: +41 56 310 3728
Paul Scherrer Institute   FAX: +41 56 310 2199
OLGA/021  mailto:[EMAIL PROTECTED]
CH-5232 Villigen PSI  http://midas.psi.ch/~stefan
[Quoted text hidden]>

>
> ELOG Web Logbook Remote Denial of Service Vulnerability
>
>
> OS2A ID: OS2A_1008Status:
>   10/31/2006  Issue Discovered
>   11/08/2006  Reported to the Vendor
>   --  Fixed by Vendor
>   --  Advisory Released
>
>
> Class: Denial of Service  Severity: Medium
>
>
> Overview:
> -
> The Electronic Logbook (ELOG) is part of a family of applications known as
> weblogs. ELOG is a remarkable implementation of a weblog in its simplicity of
> use and versatility.
> http://midas.psi.ch/elog/index.html
>
> Description:
> 
> Remote exploitation of a denial of service vulnerability in ELOG's
> elogd server allows attackers to crash the service, thereby preventing
> legitimate access.
>
> The [global]  section in configuration file elogd.cfg is used for settings
> common to all logbooks. The vulnerability is due to improper handling of an
> HTTP GET request if logbook name 'global' (or any logbook name prefixed
> with global) is used in the request. When such a request is received,
> a NULL pointer dereference occurs, leading to a crash of the service.
>
> Only authenticated users can exploit this vulnerability if the application
> is configured with password.
>
> Impact:
> ---
> Successful exploitation allows a remote attacker to crash the elogd server.
>
> Affected Software(s):
> -
> ELOG 2.6.2 and prior.
>
> Proof of Concept:
> -
> The HTTP GET request given below is sufficient to crash affected server:
> http://www.example.com/global/
>
> Analysis:
> ---
> #gdb ./elogd
> ...
> ...
>
> (gdb) break show_elog_list
> Breakpoint 2 at 0x809d6e0
>
> (gdb) c
> Continuing.
> (no debugging symbols found)
> elogd 2.6.2 built Nov  8 2006, 01:25:48 revision 1699
> Falling back to default group "elog"
> Falling back to default user "elog"
> Indexing logbooks ... done
> Server listening on port 8080 ...
>
> Breakpoint 2, 0x0809d6e0 in show_elog_list ()
> (gdb) c
> Continuing.
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x0809eb7a in show_elog_list ()
>
> (gdb) bt
> #0  0x0809eb7a in show_elog_list ()
> #1  0x in ?? ()
>
> (gdb) i r
> eax0x0  0
> ecx0x9d43d88164904328
> edx0x0  0
> ebx0x0  0
> esp0xbfa8aca0   0xbfa8aca0
> ebp0x80df40c0x80df40c
> esi0xbfb27050   -1078824880
> edi0x0  0
> eip0x809eb7a0x809eb7a
> eflags 0x200246 2097734
> cs 0x73 115
> ss 0x7b 123
> ds 0x7b 123
> es 0x7b 123
> fs 0x0  0
> gs 0x33 51
>
> (gdb) x/i $eip
> 0x809eb7a :mov(%eax),%eax
>
> The vulnerable code is at Line:16774 of elogd.c,
> n_msg = *lbs->n_el_index;
> wher

Bug#389361: XSS vulnerability fixed

[Recai Oktaş]

* Stefan Ritt [2006-09-27 23:09:27+0200]
> The reported XSS vulnerability has been fixed in SVN revision 1719 of 
> elog by not allowing HTML mode by default. This mode has to be enabled 
> explicitly by setting "Allowed encoding = 7".

Hi Stefan,

Thanks for the fix!  I haven't checked the stable version.  Does this issue
also exist in our stable version (release 2.5.7, svn revision: r1558)?  If
so, we should prepare a backport for it.

Cheers,

-- 
roktas


signature.asc
Description: Digital signature

Bug#389361: XSS vulnerability in elog

[Recai Oktaş]

* Tilman Koschnick [2006-09-25 11:27:10+0200]
> Package: elog
> Version: 2.6.1+r1642-1
> Severity: grave
> Tags: security
> Justification: user security hole
> 
> Hi,
> 
> when editing a log entry in HTML mode, elog accepts arbitrary JavaScript
> code. This code will be executed in the browser of other users viewing the
> entry (provided they have JavaScript enabled), thus exposing the users
> to a XSS (cross site scripting) attack.

Hi,

Thanks for your bug report.  I'm going to make a new upload (r1719) which
includes a fix for this issue.  Feel free to reopen this bug if the problem
persists.

-- 
roktas


signature.asc
Description: Digital signature

Bug#349528: Security bugs in elog

[Recai Oktaş]

* Moritz Muehlenhoff [2006-02-05 19:47:45+0100]
> Recai Oktaş wrote:
> > Let me know whether it is fine and I'll make the upload to stable-security
> > (right?).
> 
> Did you upload? I don't see any builds trickling in. If not, I'll do it.

Yes, uploaded on 28 January:

http://lists.debian.org/debian-changes/2006/01/msg00048.html

-- 
roktas

Bug#349528: Security bugs in elog

[Recai Oktaş]

* Recai Oktaş [2006-01-28 01:56:06+0200]
> Hmm, just found some other issues regarding this CVE-2005-4439.  Previous 
> tests had seemed fine to me, but when I made more tests, the bug came up 
> again.  I believe the attached patch should fix this completely.  Stefan, 
> could you have a look at it please?

Stefan has confirmed my patch and applied it in r1642.  So far, the 
following patches have been applied:

http://people.debian.org/~roktas/elog-backport-patches/

I've created a new package and confirmed that it works:

http://people.debian.org/~roktas/packages/elog_2.5.7+r1558-4+sarge1.diff.gz
http://people.debian.org/~roktas/packages/elog_2.5.7+r1558-4+sarge1.dsc
http://people.debian.org/~roktas/packages/elog_2.5.7+r1558-4+sarge1_i386.deb

Debdiff is attached and here is the new changelog for your convenience:

elog (2.5.7+r1558-4+sarge1) stable-security; urgency=critical

* Major security update (big thanks to Florian Weimer)
  + Backport r1333 from upstream's Subversion repository:
"Fixed crashes with very long (revisions) attributes"
  + Backport r1335 from upstream's Subversion repository:
"Applied patch from Emiliano to fix possible buffer overflow"
  + Backport r1472 from upstream's Subversion repository:
"Do not distinguish between invalid user name and invalid password
 for security reasons"
  + Backport r1487 from upstream's Subversion repository:
"Fixed infinite redirection with ?fail=1"
  + Backport r1529 from upstream's Subversion repository:
"Fixed bug with fprintf and buffer containing "%""
[Our patch just eliminates the format string vulnerability.]
  + Backport r1620 from upstream's Subversion repository:
"Prohibit '..' in URLs" [CVE-2006-0347]
  + Backport r1635 and r1642 from upstream's Subversion repository:
"Fixed potential buffer overflows" [CVE-2005-4439]

Let me know whether it is fine and I'll make the upload to stable-security
(right?).

Regards,

-- 
roktas


elog_2.5.7+r1558-3_2.5.7+r1558-4+sarge1.debdiff.gz
Description: Binary data


signature.asc
Description: Digital signature

Bug#349528: Security bugs in elog

[Recai Oktaş]

* Moritz Muehlenhoff [2006-01-27 15:28:00+0100]
> Recai Oktaş wrote:
> >   + Backport r1636 from upstream's Subversion repository:
> > "Added IP address to log file"
> 
> Why is r1636 necessary? This seems like a new feature (better logging
> in case of an attack), but doesn't seem to fix a direct security problem
> and could potentially break scripts that monitor the log file and expect
> the current logfile file format.

I'll remove it.

> The rest of the patch looks fine.

Hmm, just found some other issues regarding this CVE-2005-4439.  Previous 
tests had seemed fine to me, but when I made more tests, the bug came up 
again.  I believe the attached patch should fix this completely.  Stefan, 
could you have a look at it please?

-- 
roktas
Subject: [PATCH]: More Fixes for CVE-2005-4439: buffer overflow through 
 long URL parameters

--- a/src/elogd.c   2006-01-27 10:27:21.0 +0200
+++ b/src/elogd.c   2006-01-28 01:31:33.0 +0200
@@ -23205,7 +23205,7 @@ void server_loop(void)
 {
int status, i, n, n_error, authorized, min, i_min, i_conn, length;
struct sockaddr_in serv_addr, acc_addr;
-   char pwd[256], str[1000], url[256], cl_pwd[256], *p, *pd;
+   char pwd[256], str[1000], url[256], cl_pwd[256], *p;
char cookie[256], boundary[256], list[1000], theme[256],
host_list[MAX_N_LIST][NAME_LENGTH], logbook[256], logbook_enc[256], 
global_cmd[256];
int lsock, len, flag, content_length, header_length;
@@ -23756,7 +23756,7 @@ void server_loop(void)
 p = strchr(net_buffer, '/') + 1;
 
 /* check for ../.. to avoid serving of files on top of the elog 
directory */
-for (i = 0; p[i] && p[i] != ' ' && p[i] != '?'; i++)
+for (i = 0; p[i] && p[i] != ' ' && p[i] != '?' && i < (int) 
sizeof(url); i++)
url[i] = p[i];
 url[i] = 0;
 
@@ -23774,7 +23774,7 @@ void server_loop(void)
 }
 
 /* check if file is in scripts directory or in its subdirs */
-for (i = 0; p[i] && p[i] != ' ' && p[i] != '?'; i++)
+for (i = 0; p[i] && p[i] != ' ' && p[i] != '?' && i < (int) 
sizeof(url); i++)
url[i] = (p[i] == '/') ? DIR_SEPARATOR : p[i];
 url[i] = 0;
 if (strchr(url, '.')) {
@@ -23810,7 +23810,7 @@ void server_loop(void)
 }
 
 logbook[0] = 0;
-for (i = 0; *p && *p != '/' && *p != '?' && *p != ' '; i++)
+for (i = 0; *p && *p != '/' && *p != '?' && *p != ' ' && i < (int) 
sizeof(logbook); i++)
logbook[i] = *p++;
 logbook[i] = 0;
 strcpy(logbook_enc, logbook);
@@ -23831,10 +23831,9 @@ void server_loop(void)
 /* check for trailing '/' after logbook/ID */
 if (logbook[0] && *p == '/' && *(p + 1) != ' ') {
sprintf(url, "%s", logbook_enc);
-   pd = url + strlen(url);
-   while (*p && *p != ' ')
-  *pd++ = *p++;
-   *pd = 0;
+  for (i = strlen(url); *p &&  *p != ' ' && i < (int) sizeof(url); 
i++)
+ url[i] = *p++;
+  url[i] = 0;
if (*(p - 1) == '/') {
   sprintf(str, "Invalid URL: %s", url);
   show_error(str);
@@ -24109,7 +24108,8 @@ void server_loop(void)
   goto redir;
} else if (strncmp(net_buffer, "GET", 3) == 0) {
   /* extract path and commands */
-  *strchr(net_buffer, '\r') = 0;
+  if (strchr(net_buffer, '\r'))
+ *strchr(net_buffer, '\r') = 0;
   if (!strstr(net_buffer, "HTTP/1"))
  goto finished;
   *(strstr(net_buffer, "HTTP/1") - 1) = 0;


signature.asc
Description: Digital signature

Bug#349528: (no subject)

[Recai Oktaş]

[sorry for the delay, my internet connection is sketchy these days]

* Moritz Muehlenhoff [2006-01-26 10:57:53+0100]
> Florian, thanks a lot for sorting this out!
> I'll prepare the DSA; Recai, what cosmetic fixes do you intent
> to do? A security upload's changes you be strictly limited to the
> security issues. 

Only changes in debian/changelog (adopt my changelog style).

> Can you send me the debdiff between the Sarge version and your proposed
> upload to the security queue or the proposed update itself?

Debdiff is attached.  You can reach the proposed update at the following
uri:

http://people.debian.org/~roktas/packages/elog_2.5.7+r1558-4+sarge1.diff.gz
http://people.debian.org/~roktas/packages/elog_2.5.7+r1558-4+sarge1.dsc
http://people.debian.org/~roktas/packages/elog_2.5.7+r1558-4+sarge1_i386.deb

And here is the relevant changelog entry for your inspection:

  elog (2.5.7+r1558-4+sarge1) stable-security; urgency=high
  
* Major security update (big thanks to Florian Weimer)
  + Backport r1333 from upstream's Subversion repository:
"Fixed crashes with very long (revisions) attributes"
  + Backport r1335 from upstream's Subversion repository:
"Applied patch from Emiliano to fix possible buffer overflow"
  + Backport r1472 from upstream's Subversion repository:
"Do not distinguish between invalid user name and invalid password
 for security reasons"
  + Backport r1487 from upstream's Subversion repository:
"Fixed infinite redirection with ?fail=1"
  + Backport r1529 from upstream's Subversion repository:
"Fixed bug with fprintf and buffer containing "%""
[Our patch just eliminates the format string vulnerability.]
  + Backport r1620 from upstream's Subversion repository:
"Prohibit '..' in URLs" [CVE-2006-0347]
  + Backport r1635 from upstream's Subversion repository:
"Fixed potential buffer overflows" [CVE-2005-4439]
  + Backport r1636 from upstream's Subversion repository:
"Added IP address to log file"

* Florian Weimer [2006-01-26 13:41:53+0100]
> So far, the patch for CVE-2006-0347 was missing. A tentative backport
> of the upstream fix is included below.  I dropped the hunk which dealt
> with "scripts" support because this functionality is not present in
> the sarge version.
> 
> The changelog entry should look like this:
> 
>   Backport revision 1620 from upstream Subversion repository:
>   "Prohibit '..' in URLs" [CVE-2006-0347]

Hmm, I should have checked the CVE database for other issues.  Thanks for 
doing it on behalf of me.  I have applied the above patch and tested it for 
a failure case explained in Elog forums:

http://midas.psi.ch/elogs/Forum/1615

It seems fine here (Elog returns an "Invalid URL" message).

Regards,

-- 
roktas


elog_2.5.7+r1558-3_2.5.7+r1558-4+sarge1.debdiff.gz
Description: Binary data


signature.asc
Description: Digital signature

Bug#349528: Security bugs in elog

[Recai Oktaş]

* Recai Oktaş [2006-01-25 09:34:15+0200]
> All three patches + your previous six patches were applied and compiled
> successfully.  I've also tested the fixed package in my system without any
> glitches.  Now, I'm going to build and test it in a Sarge chroot jail.

I've just tested the _pbuilded_ Sarge package against the CVE-2005-4439
vulnerability and confirmed that elogd behaved normally (no core dump).

Florian: If you haven't any objections, I'll upload to stable-security
(with some final cosmetic touches).  Also, the new upstream package will
follow (for sid).

Stefan: Thank you very much for the urgent fix.

Regards,

-- 
roktas


signature.asc
Description: Digital signature

Bug#349528: Security bugs in elog

[Recai Oktaş]

* Florian Weimer [2006-01-24 21:51:00+0100]
> * Stefan Ritt:
> >> Is this list complete as far as fixes past r1202 are concerned?  What
> >> about r1487, is it a significant DoS condition?
> >
> > Yes.
> 
> Okay, this patch shouldn't be too hard to extract.  Recai, could you
> backport that one and the fixes from r1635 to stable?

OK.  I'm sending three separate patches attached for your review:

* 0007-r1635-Fix-CVE-2005-4439.txt
  Backport r1635: targets to fix CVE-2005-4439

* 0008-r1487-Fix-DoS-condition.txt
  Backport r1487: fixes infinite redirection

* 0009-r1636-Add-IP-address-to-logfile.txt [optional]
  Backport r1636: adds IP address to log file

All three patches + your previous six patches were applied and compiled
successfully.  I've also tested the fixed package in my system without any
glitches.  Now, I'm going to build and test it in a Sarge chroot jail.

Hope I haven't missed anything.

Regards,

-- 
roktas
Subject: [PATCH] r1635: Fixes CVE-2005-4439: buffer overflow through long URL
 parameters

--- a/debian/changelog  2006-01-25 08:24:44.0 +0200
+++ b/debian/changelog  2006-01-25 08:24:50.0 +0200
@@ -11,6 +11,10 @@ elog (2.5.7+r1558-4+sarge1) unstable; ur
   * Backport r1529 from upstream's Subversion repository:
 "Fixed bug with fprintf and buffer containing "%""
 (Our patch just eliminates the format string vulnerability.)
+  * Backport r1635 from upstream's Subversion repository:
+"Fixed potential buffer overflows"
+This backport addresses CVE-2005-4439: buffer overflow through long
+URL parameters 
 
  -- Florian Weimer <[EMAIL PROTECTED]>  Mon, 23 Jan 2006 15:56:37 +0100

--- a/src/elogd.c   2006-01-25 08:21:00.0 +0200
+++ b/src/elogd.c   2006-01-25 08:21:48.0 +0200
@@ -1839,13 +1839,15 @@ void base64_decode(char *s, char *d)
*d = 0;
 }
 
-void base64_encode(char *s, char *d)
+void base64_encode(unsigned char *s, unsigned char *d, int size)
 {
unsigned int t, pad;
+   unsigned char *p;
 
pad = 3 - strlen(s) % 3;
if (pad == 3)
   pad = 0;
+   p = d;
while (*s) {
   t = (*s++) << 16;
   if (*s)
@@ -1862,6 +1864,8 @@ void base64_encode(char *s, char *d)
   *(d + 0) = map[t & 63];
 
   d += 4;
+  if (d-p >= size-3)
+ return;
}
*d = 0;
while (pad--)
@@ -1898,12 +1902,12 @@ void base64_bufenc(unsigned char *s, int
   *(--d) = '=';
 }
 
-void do_crypt(char *s, char *d)
+void do_crypt(char *s, char *d, int size)
 {
 #ifdef HAVE_CRYPT
-   strcpy(d, crypt(s, "el"));
+   strlcpy(d, crypt(s, "el"), size);
 #else
-   base64_encode(s, d);
+   base64_encode((unsigned char *) s, (unsigned char *) d, size);
 #endif
 }
 
@@ -2652,7 +2656,7 @@ int retrieve_url(char *url, char **buffe
 {
struct sockaddr_in bind_addr;
struct hostent *phe;
-   char str[256], host[256], subdir[256], param[256], auth[256], pwd_enc[256];
+   char str[1000], unm[256], upwd[256], host[256], subdir[256], param[256], 
auth[256], pwd_enc[256];
int port, bufsize;
INT i, n;
fd_set readfds;
@@ -2704,12 +2708,15 @@ int retrieve_url(char *url, char **buffe
sprintf(str, "GET %s%s HTTP/1.0\r\nConnection: Close\r\n", subdir, param);
 
/* add local username/password */
-   if (isparam("unm"))
+   if (isparam("unm") && isparam("upwd")) {
+  strlcpy(unm, getparam("unm"), sizeof(unm));
+  strlcpy(upwd, getparam("upwd"), sizeof(upwd));
   sprintf(str + strlen(str), "Cookie: unm=%s; upwd=%s\r\n", 
getparam("unm"), getparam("upwd"));
+   }
 
if (rpwd && rpwd[0]) {
   sprintf(auth, "anybody:%s", rpwd);
-  base64_encode(auth, pwd_enc);
+  base64_encode((unsigned char *) auth, (unsigned char *) pwd_enc, 
sizeof(pwd_enc));
   sprintf(str + strlen(str), "Authorization: Basic %s\r\n", pwd_enc);
}
 
@@ -3523,13 +3530,13 @@ void check_config()
 
 void retrieve_email_from(LOGBOOK * lbs, char *ret, char 
attrib[MAX_N_ATTR][NAME_LENGTH])
 {
-   char str[256], *p, login_name[256];
+   char email_from[256], str[256], *p, login_name[256];
char slist[MAX_N_ATTR + 10][NAME_LENGTH], svalue[MAX_N_ATTR + 
10][NAME_LENGTH];
int i;
 
if (!getcfg(lbs->name, "Use Email from", str, sizeof(str))) {
   if (isparam("user_email") && *getparam("user_email"))
- strcpy(str, getparam("user_email"));
+ strlcpy(str, getparam("user_email"), sizeof(email_from));
   else
  sprintf(str, "[EMAIL PROTECTED]", host_name);
}
@@ -5254,7 +5261,7 @@ void write_logfile(LOGBOOK * lbs, const 
 {
char file_name[2000];
va_list argptr;
-   char str[1];
+   char str[1], unm[256];
FILE *f;
time_t now;
char buf[1];
@@ -5284,9 +5291,10 @@ void write_logfile(LOGBOOK * lbs, const 
strftime(buf, sizeof(buf), "%d-%b-%Y %H:%M:%S", localtime(&now));
strcat(buf, " ");
 
-   if (*getparam("unm") && rem_host[0])
-  sprintf(buf + strlen(buf), "[EMAI

Bug#349528: various unfixed security bugs

[Recai Oktaş]

Hi,

* Florian Weimer [2006-01-24 00:07:35+0100]
> * Recai Oktaş:
> 
> > I'm going to prepare an urgent sid upload for those bugs.
> 
> I'm not sure if it is worth the effort, until we have all other issues
> sorted out.

Agreed.  I would be glad if you add yourself in "Uploaders" field.  You're
totally free to make any upload.

-- 
roktas


signature.asc
Description: Digital signature

Bug#349528: various unfixed security bugs

[Recai Oktaş]

First of all thanks for the detailed analysis!  I haven't been able to work
on elog much, due to heavy work load these days.

* Florian Weimer [2006-01-23 16:42:16+0100]
> Package: elog
> Version: 2.6.0beta2+r1716-1
> Tags: security upstream fixed-upstream
> Severity: grave
> 
> First a little version cross-reference, based on the src/elog{,d}.c
> files.
> 
>   Debian  CVS (elogd.c)Subversion
>   2.6.0beta2+r1716-1  1.717*   r1445
>   2.5.7+r1558-3   1.558 + 1.648r1202 + r1347
> 
> * Part of the upstream are contained in the .diff.gz file, so the
>   embedded version number is not quite correct.
> 
> The following issues are unfixed upstream:
> 
>   - CVE-2005-4439: buffer overflow through long URL parameters
> 
> 
>   - If host names are resolved, no forward lookup is performed to
> verify the PTR RR.  (This does not affect the sarge version
> because it unconditionally uses addresses, not host names.)
> 
>   - There are still some format string issues when things are written
> to the logfile.
> 
> Apparently, upstream is not aware of those three issues.
> 
> The following potential security issues have been fixed upstream, but
> not in the sid version (there are some more issues apparently, but
> those bugs were introduced past the sid version AFAICS):

I'm going to prepare an urgent sid upload for those bugs.

>
> 
> r1529 | ritt | 2005-10-25 20:26:34 +0200 (Tue, 25 Oct 2005) | 1 line
> Changed paths:
>M /trunk/src/elogd.c
> 
> Fixed bug with fprintf and buffer containing "%"
> 
> 
> r1472 | ritt | 2005-08-04 22:26:35 +0200 (Thu, 04 Aug 2005) | 2 lines
> Changed paths:
>M /trunk/src/elog.c
>M /trunk/src/elogd.c
> 
> Do not distinguish between invalid user name and invalid password for 
> security reasons
> 
> 
> 
> On top of that, the following issues affect the sarge version only:
> 
> 
> r1335 | ritt | 2005-04-27 12:43:43 +0200 (Wed, 27 Apr 2005) | 2 lines
> Changed paths:
>M /trunk/src/elogd.c
> 
> Applied patch from Emiliano to fix possible buffer overflow
> 
> 
> r1333 | ritt | 2005-04-22 15:41:18 +0200 (Fri, 22 Apr 2005) | 2 lines
> Changed paths:
>M /trunk/src/elogd.c
> 
> Fixed crashes with very long (revisions) attributes
> 
> 
> I've back-ported all four issues to the sarge version, but they
> haven't received any testing yet.  If anybody has got a sarge elog
> installation, please speak up.

Thanks for the backport, unfortunately I don't have a Sarge box at the
moment, but will try to find one.  Could you please supply the url of
backported patch so that I can also work on it?

> I'm going to ask upstream about the following issue:
> 
> 
> r1487 | ritt | 2005-09-09 22:59:46 +0200 (Fri, 09 Sep 2005) | 2 lines
> Changed paths:
>M /trunk/src/elogd.c
> 
> Fixed infinite redirection with ?fail=1

CCing to Stefan.

[Stefan: Please keep the discussion CCed to the bug report]

Regards,

-- 
roktas


signature.asc
Description: Digital signature