Debian Bug report logs - #610834
maradns: crash on long name queries

version graph

Package: maradns; Maintainer for maradns is Dariusz Dwornikowski <dariusz.dwornikowski@cs.put.poznan.pl>; Source for maradns is src:maradns.

Reported by: "Witold Baryluk" <baryluk@smp.if.uj.edu.pl>

Date: Sun, 23 Jan 2011 04:12:01 UTC

Severity: important

Tags: security

Found in version maradns/1.4.03-1

Fixed in version maradns/1.4.03-1.1

Done: Moritz Muehlenhoff <jmm@debian.org>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Kai Hendry <hendry@iki.fi>:
Bug#610834; Package maradns. (Sun, 23 Jan 2011 04:12:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to "Witold Baryluk" <baryluk@smp.if.uj.edu.pl>:
New Bug report received and forwarded. Copy sent to Kai Hendry <hendry@iki.fi>. (Sun, 23 Jan 2011 04:12:04 GMT) Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: "Witold Baryluk" <baryluk@smp.if.uj.edu.pl>
To: submit@bugs.debian.org
Subject: maradns: crash on long name queries
Date: Sun, 23 Jan 2011 05:10:37 +0100
Package: maradns
Version: 1.4.03-1
Severity: important
Tags: security

This bug can lead to DoS.


DNS name

w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.pl

is valid name, which even resolves to ipv4 address.

I have maradns on localhost, and maradns looks to answer,
but immiedietly segfaults.

# /etc/init.d/maradns start
Starting maradns: maradns.

# ps aux | grep mara
maradns   1472  0.0  0.0   1972   760 pts/2    S    04:33   0:00 /usr/sbin/maradns -f /etc/maradns/mararc
root      1473  0.0  0.0   3164   596 pts/2    S    04:33   0:00 logger -p daemon.notice -t maradns.etc_maradns_mararc

# host
w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.pl
127.0.0.1
Using domain server:
Name: 127.0.0.1
Address: 127.0.0.1#53
Aliases:

w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.pl
has address 195.114.173.133
;; connection timed out; no servers could be reached
# ps aux | grep mara
baryluk   1353  2.6  2.0 125420 43120 pts/7    Sl+  04:32   0:06 /usr/bin/python /usr/bin/reportbug maradns
#


Actually given example isn't biggest allowed.
Adding additional "w." component, gives very strange error.


# host
w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.pl
127.0.0.1
;; Warning: Message parser reports malformed message packet.
;; Warning: Message parser reports malformed message packet.
Using domain server:
Name: 127.0.0.1
Address: 127.0.0.1#53
Aliases:

Host
w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.pl
not found: 2(SERVFAIL)
#

There is a change that the last problem is a problem in host utility,
but I do not think so as, it performs strict
lengths checks (even reports that name is not legal if any compontent is
longer than 63, or whole name is longer than 254 characters).
To be sure what are limits check DNS RFCs.

PS. I also tested deadwood, and it also behaves in very strange way.
It do not segfaults, but timeouts. I incressed timeouts in nslookup utility,
and still no answer from deadwood. I guess too big recursion level.
Please check it also.


-- System Information:
Debian Release: 6.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core)
Locale: LANG=pl_PL.utf8, LC_CTYPE=pl_PL.utf8 (charmap=UTF-8) (ignored: LC_ALL set to pl_PL.utf8)
Shell: /bin/sh linked to /bin/dash

Versions of packages maradns depends on:
ii  adduser                       3.112+nmu2 add and remove users and groups
ii  libc6                         2.11.2-9   Embedded GNU C Library: Shared lib

maradns recommends no packages.

maradns suggests no packages.

-- Configuration Files:
/etc/init.d/maradns changed [not included]
/etc/maradns/mararc changed [not included]

-- no debconf information




Message sent on to "Witold Baryluk" <baryluk@smp.if.uj.edu.pl>:
Bug#610834. (Mon, 24 Jan 2011 01:57:15 GMT) Full text and rfc822 format available.

Message #8 received at 610834-submitter@bugs.debian.org (full text, mbox):

From: Raphael Geissert <geissert@debian.org>
To: oss-security@lists.openwall.com
Cc: maradns@gmail.com, 610834-submitter@bugs.debian.org
Subject: CVE request: MaraDNS DoS via long queries
Date: Sun, 23 Jan 2011 19:55:40 -0600
Hi,

A crash bug has been reported against MaraDNS 1.4.03 when long queries are 
sent to the resolver. Details can be found at:
http://bugs.debian.org/610834

As of the time of writing, the reporter is testing other versions and at least 
1.4.05 also seems to be affected.

Josh, Steven: could a CVE id be assigned? Thanks in advance.

Regards,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net




Information forwarded to debian-bugs-dist@lists.debian.org, Kai Hendry <hendry@iki.fi>:
Bug#610834; Package maradns. (Mon, 24 Jan 2011 02:00:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to "Witold Baryluk" <baryluk@smp.if.uj.edu.pl>:
Extra info received and forwarded to list. Copy sent to Kai Hendry <hendry@iki.fi>. (Mon, 24 Jan 2011 02:00:07 GMT) Full text and rfc822 format available.

Message #13 received at 610834@bugs.debian.org (full text, mbox):

From: "Witold Baryluk" <baryluk@smp.if.uj.edu.pl>
To: 610834@bugs.debian.org
Cc: atomo64@gmail.com
Subject: backtrace
Date: Mon, 24 Jan 2011 02:57:44 +0100
[Message part 1 (text/plain, inline)]
Here is a backtrace of error from both sid version as well upstream most recent version (1.4.05).

I also give my config file at end.

Compiled with CFLAGS="-O1 -g" (by modifing build system)




backtrace for debian's maradns 1.4.03-1

sredniczarny:/home/baryluk/Dane/linux/maradns-dos/maradns-1.4.03# gdb ./server/maradns
GNU gdb (GDB) 7.2-debian
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /sctank2/Dane/linux/maradns-dos/maradns-1.4.03/server/maradns...done.
(gdb) run -f /etc/maradns/mararc
Starting program: /sctank2/Dane/linux/maradns-dos/maradns-1.4.03/server/maradns -f /etc/maradns/mararc
[Thread debugging using libthread_db enabled]
Adding root nameserver icann for zone .
 Log: Root directory changed
 Log: Binding to address 127.0.0.1
 Log: Socket opened on UDP port 53
 Log: Root privileges dropped
 Log: All RRs have been loaded
[New Thread 0xb7e5db70 (LWP 8726)]
[New Thread 0xb765cb70 (LWP 8727)]
[Thread 0xb7e5db70 (LWP 8726) exited]
[New Thread 0xb7e5db70 (LWP 8728)]
[Thread 0xb765cb70 (LWP 8727) exited]
maradns: malloc.c:3097: sYSMALLOc: Assertion `(old_top == (((mbinptr) (((char *) &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk, fd)))) && old_size == 0) || ((unsigned long) (old_size) >= (unsigned long)((((__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 * (sizeof(size_t))) - 1)) & ~((2 * (sizeof(size_t))) - 1))) && ((old_top)->size & 0x1) && ((unsigned long)old_end & pagemask) == 0)' failed.

Program received signal SIGABRT, Aborted.
[Switching to Thread 0xb7e5db70 (LWP 8728)]
0xb7fe2424 in __kernel_vsyscall ()
(gdb) bt
#0  0xb7fe2424 in __kernel_vsyscall ()
#1  0xb7e8a751 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2  0xb7e8db82 in abort () at abort.c:92
#3  0xb7ecb484 in __malloc_assert (assertion=<value optimized out>, file=<value optimized out>, line=3097, function=0xb7f8249c "sYSMALLOc") at malloc.c:352
#4  0xb7ece136 in sYSMALLOc (av=<value optimized out>, bytes=<value optimized out>) at malloc.c:3094
#5  _int_malloc (av=<value optimized out>, bytes=<value optimized out>) at malloc.c:4747
#6  0xb7ecfc8c in __libc_malloc (bytes=2051) at malloc.c:3661
#7  0x0805bd4f in js_alloc (unit_count=2051, unit_size=1) at JsStrOS.c:66
#8  0x0805ab88 in js_create (max_count=2048, unit_size=1) at JsStr.c:34
#9  0x0805677c in query_nameserver (remote_ip=1472994316, query=0x8096100, bailiwick=0x8096558) at recursive.c:1570
#10 0x08058b41 in recurse_call (id=53801, sock=6, client=..., query=0x8096100, queries_sent=1, glueless_level=1, ipret=0xb7e5d330, ptrret=0x0) at recursive.c:3115
#11 0x08058c90 in recurse_call (id=53801, sock=6, client=..., query=0x8095bc8, queries_sent=0, glueless_level=0, ipret=0x0, ptrret=0x0) at recursive.c:3158
#12 0x08059151 in recurse_thread (req=0x8095d70) at recursive.c:2637
#13 0xb7fab955 in start_thread (arg=0xb7e5db70) at pthread_create.c:300
#14 0xb7f2be7e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130
(gdb) q






backtrace for upstream 1.4.5 (only changed CFLAGS to -g -O0)

Starting program: /sctank2/Dane/linux/maradns-dos/recent/maradns-1.4.05/server/maradns -f /etc/maradns/mararc
[Thread debugging using libthread_db enabled]
Adding root nameserver icann for zone .
 Log: Root directory changed
 Log: Binding to address 127.0.0.1
 Log: Socket opened on UDP port 53
 Log: Root privileges dropped
 Log: All RRs have been loaded
[New Thread 0xb7e5db70 (LWP 10277)]
[Thread 0xb7e5db70 (LWP 10277) exited]
[New Thread 0xb765cb70 (LWP 10278)]
[New Thread 0xb7e5db70 (LWP 10279)]
[Thread 0xb765cb70 (LWP 10278) exited]
maradns: malloc.c:3097: sYSMALLOc: Assertion `(old_top == (((mbinptr) (((char *) &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk, fd)))) && old_size == 0) || ((unsigned long) (old_size) >= (unsigned long)((((__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 * (sizeof(size_t))) - 1)) & ~((2 * (sizeof(size_t))) - 1))) && ((old_top)->size & 0x1) && ((unsigned long)old_end & pagemask) == 0)' failed.

Program received signal SIGABRT, Aborted.
[Switching to Thread 0xb7e5db70 (LWP 10279)]
0xb7fe2424 in __kernel_vsyscall ()
(gdb) bt
#0  0xb7fe2424 in __kernel_vsyscall ()
#1  0xb7e8a751 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2  0xb7e8db82 in abort () at abort.c:92
#3  0xb7ecb484 in __malloc_assert (assertion=<value optimized out>, file=<value optimized out>, line=3097, function=0xb7f8249c "sYSMALLOc") at malloc.c:352
#4  0xb7ece136 in sYSMALLOc (av=<value optimized out>, bytes=<value optimized out>) at malloc.c:3094
#5  _int_malloc (av=<value optimized out>, bytes=<value optimized out>) at malloc.c:4747
#6  0xb7ecfc8c in __libc_malloc (bytes=2051) at malloc.c:3661
#7  0x0805f63c in js_alloc (unit_count=2051, unit_size=1) at JsStrOS.c:66
#8  0x0805dfb3 in js_create (max_count=2048, unit_size=1) at JsStr.c:34
#9  0x080568be in query_nameserver (remote_ip=1472994316, query=0x8089e20, bailiwick=0x809e318) at recursive.c:1570
#10 0x08059843 in recurse_call (id=32218, sock=6, client=..., query=0x8089e20, queries_sent=1, glueless_level=1, ipret=0xb7e5d2ec, ptrret=0x0) at recursive.c:3115
#11 0x080599c1 in recurse_call (id=32218, sock=6, client=..., query=0x809e518, queries_sent=0, glueless_level=0, ipret=0x0, ptrret=0x0) at recursive.c:3158
#12 0x0805877f in recurse_thread (req=0x809c4a0) at recursive.c:2637
#13 0xb7fab955 in start_thread (arg=0xb7e5db70) at pthread_create.c:300
#14 0xb7f2be7e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130
(gdb) q
A debugging session is active.

Inferior 1 [process 10267] will be killed.

Quit anyway? (y or n) y
sredniczarny:/home/baryluk/Dane/linux/maradns-dos/recent/maradns-1.4.05#








Valgrind report for 1.4.05:

sredniczarny:/home/baryluk/Dane/linux/maradns-dos/recent/maradns-1.4.05# valgrind   ./server/maradns  -f /etc/maradns/mararc
==10341== Memcheck, a memory error detector
==10341== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==10341== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info
==10341== Command: ./server/maradns -f /etc/maradns/mararc
==10341== 
Adding root nameserver icann for zone .
 Log: Root directory changed
 Log: Binding to address 127.0.0.1
 Log: Socket opened on UDP port 53
 Log: Root privileges dropped
 Log: All RRs have been loaded
==10341== Thread 3:
==10341== Invalid write of size 4
==10341==    at 0x8063971: compress_add_dlabel_points (Compress.c:200)
==10341==    by 0x8063E22: compress_dlabel (Compress.c:390)
==10341==    by 0x806413F: compress_rddata (Compress.c:527)
==10341==    by 0x80648F5: compress_answers (Compress.c:899)
==10341==    by 0x80649E3: compress_data (Compress.c:960)
==10341==    by 0x804C838: udpnotfound (MaraDNS.c:2070)
==10341==    by 0x805839C: give_answer (recursive.c:2524)
==10341==    by 0x8058CE5: recurse_call (recursive.c:2794)
==10341==    by 0x8059AE7: recurse_call (recursive.c:3191)
==10341==    by 0x805877E: recurse_thread (recursive.c:2637)
==10341==    by 0x404E954: start_thread (pthread_create.c:300)
==10341==    by 0x412EE7D: clone (clone.S:130)
==10341==  Address 0x42db290 is 512 bytes inside a block of size 515 alloc'd
==10341==    at 0x4023F50: malloc (vg_replace_malloc.c:236)
==10341==    by 0x805F63B: js_alloc (JsStrOS.c:66)
==10341==    by 0x8063781: compress_init_state (Compress.c:90)
==10341==    by 0x8064962: compress_data (Compress.c:940)
==10341==    by 0x804C838: udpnotfound (MaraDNS.c:2070)
==10341==    by 0x805839C: give_answer (recursive.c:2524)
==10341==    by 0x8058CE5: recurse_call (recursive.c:2794)
==10341==    by 0x8059AE7: recurse_call (recursive.c:3191)
==10341==    by 0x805877E: recurse_thread (recursive.c:2637)
==10341==    by 0x404E954: start_thread (pthread_create.c:300)
==10341==    by 0x412EE7D: clone (clone.S:130)
==10341== 
==10341== Invalid read of size 4
==10341==    at 0x8063B74: compress_sub_dlabel (Compress.c:289)
==10341==    by 0x8063DFA: compress_dlabel (Compress.c:382)
==10341==    by 0x806413F: compress_rddata (Compress.c:527)
==10341==    by 0x80648F5: compress_answers (Compress.c:899)
==10341==    by 0x80649E3: compress_data (Compress.c:960)
==10341==    by 0x804C838: udpnotfound (MaraDNS.c:2070)
==10341==    by 0x805839C: give_answer (recursive.c:2524)
==10341==    by 0x8058CE5: recurse_call (recursive.c:2794)
==10341==    by 0x8059AE7: recurse_call (recursive.c:3191)
==10341==    by 0x805877E: recurse_thread (recursive.c:2637)
==10341==    by 0x404E954: start_thread (pthread_create.c:300)
==10341==    by 0x412EE7D: clone (clone.S:130)
==10341==  Address 0x42db290 is 512 bytes inside a block of size 515 alloc'd
==10341==    at 0x4023F50: malloc (vg_replace_malloc.c:236)
==10341==    by 0x805F63B: js_alloc (JsStrOS.c:66)
==10341==    by 0x8063781: compress_init_state (Compress.c:90)
==10341==    by 0x8064962: compress_data (Compress.c:940)
==10341==    by 0x804C838: udpnotfound (MaraDNS.c:2070)
==10341==    by 0x805839C: give_answer (recursive.c:2524)
==10341==    by 0x8058CE5: recurse_call (recursive.c:2794)
==10341==    by 0x8059AE7: recurse_call (recursive.c:3191)
==10341==    by 0x805877E: recurse_thread (recursive.c:2637)
==10341==    by 0x404E954: start_thread (pthread_create.c:300)
==10341==    by 0x412EE7D: clone (clone.S:130)
==10341== 
==10341== Invalid read of size 4
==10341==    at 0x80638A9: compress_add_dlabel_points (Compress.c:167)
==10341==    by 0x8063E22: compress_dlabel (Compress.c:390)
==10341==    by 0x806413F: compress_rddata (Compress.c:527)
==10341==    by 0x80648F5: compress_answers (Compress.c:899)
==10341==    by 0x80649E3: compress_data (Compress.c:960)
==10341==    by 0x804C838: udpnotfound (MaraDNS.c:2070)
==10341==    by 0x805839C: give_answer (recursive.c:2524)
==10341==    by 0x8058CE5: recurse_call (recursive.c:2794)
==10341==    by 0x8059AE7: recurse_call (recursive.c:3191)
==10341==    by 0x805877E: recurse_thread (recursive.c:2637)
==10341==    by 0x404E954: start_thread (pthread_create.c:300)
==10341==    by 0x412EE7D: clone (clone.S:130)
==10341==  Address 0x42db290 is 512 bytes inside a block of size 515 alloc'd
==10341==    at 0x4023F50: malloc (vg_replace_malloc.c:236)
==10341==    by 0x805F63B: js_alloc (JsStrOS.c:66)
==10341==    by 0x8063781: compress_init_state (Compress.c:90)
==10341==    by 0x8064962: compress_data (Compress.c:940)
==10341==    by 0x804C838: udpnotfound (MaraDNS.c:2070)
==10341==    by 0x805839C: give_answer (recursive.c:2524)
==10341==    by 0x8058CE5: recurse_call (recursive.c:2794)
==10341==    by 0x8059AE7: recurse_call (recursive.c:3191)
==10341==    by 0x805877E: recurse_thread (recursive.c:2637)
==10341==    by 0x404E954: start_thread (pthread_create.c:300)
==10341==    by 0x412EE7D: clone (clone.S:130)
==10341== 
==10341== Invalid write of size 4
==10341==    at 0x806395E: compress_add_dlabel_points (Compress.c:199)
==10341==    by 0x8063E22: compress_dlabel (Compress.c:390)
==10341==    by 0x806413F: compress_rddata (Compress.c:527)
==10341==    by 0x80648F5: compress_answers (Compress.c:899)
==10341==    by 0x80649E3: compress_data (Compress.c:960)
==10341==    by 0x804C838: udpnotfound (MaraDNS.c:2070)
==10341==    by 0x805839C: give_answer (recursive.c:2524)
==10341==    by 0x8058CE5: recurse_call (recursive.c:2794)
==10341==    by 0x8059AE7: recurse_call (recursive.c:3191)
==10341==    by 0x805877E: recurse_thread (recursive.c:2637)
==10341==    by 0x404E954: start_thread (pthread_create.c:300)
==10341==    by 0x412EE7D: clone (clone.S:130)
==10341==  Address 0x42db290 is 512 bytes inside a block of size 515 alloc'd
==10341==    at 0x4023F50: malloc (vg_replace_malloc.c:236)
==10341==    by 0x805F63B: js_alloc (JsStrOS.c:66)
==10341==    by 0x8063781: compress_init_state (Compress.c:90)
==10341==    by 0x8064962: compress_data (Compress.c:940)
==10341==    by 0x804C838: udpnotfound (MaraDNS.c:2070)
==10341==    by 0x805839C: give_answer (recursive.c:2524)
==10341==    by 0x8058CE5: recurse_call (recursive.c:2794)
==10341==    by 0x8059AE7: recurse_call (recursive.c:3191)
==10341==    by 0x805877E: recurse_thread (recursive.c:2637)
==10341==    by 0x404E954: start_thread (pthread_create.c:300)
==10341==    by 0x412EE7D: clone (clone.S:130)
==10341== 




....   maradns do not crash here, and still runs here (this is probably becuase valgrind changes libc malloc/free, so it is here not so catastrophic)









Configuration file


sredniczarny:/home/baryluk/Dane/linux/maradns-dos/maradns-1.4.03# egrep -v '^#|^$' /etc/maradns/mararc 
csv1 = {}
bind_address = "127.0.0.1"
chroot_dir = "/etc/maradns"
maradns_uid = 132
maradns_gid = 141
maxprocs = 96
no_fingerprint = 0
default_rrany_set = 3
max_chain = 8
max_ar_chain = 1
max_total = 20
verbose_level = 1
ipv4_alias = {}
ipv4_alias["icann"] = "198.41.0.4,192.228.79.201,192.33.4.12,128.8.10.90,192.203.230.10,192.5.5.241,192.112.36.4,128.63.2.53,192.36.148.17,192.58.128.30,193.0.14.129,199.7.83.42,202.12.27.33"
ipv4_alias["osrc"] = "199.166.24.1,205.189.73.102,199.166.24.3,207.126.103.16,195.117.6.10,205.189.73.10,204.57.55.100,213.196.2.97"
ipv4_alias["alternic"] = "160.79.129.192,24.6.78.12,160.79.133.70,65.15.8.202,216.162.42.240,195.224.64.190,160.79.133.66,216.162.42.185"
ipv4_alias["opennic"] = "131.161.247.226,209.151.84.102,64.247.218.140,64.247.218.149,209.104.33.250,209.104.63.249,209.151.84.103,199.175.137.211,207.6.128.246,65.243.92.254"
ipv4_alias["lokalna"] = "169.254.0.0/16"
ipv4_alias["localhost"] = "127.0.0.0/8"
ipv4_alias["xen"] = "10.0.42.0/24"
recursive_acl = "localhost,lokalna,xen"
maximum_cache_elements = 4096
ipv4_alias["polskie_rooty"] = "195.187.245.44,193.0.80.11,212.51.192.5,217.17.34.50,149.156.1.3,149.156.2.101,80.50.50.10,193.0.0.193,157.25.5.30,192.36.125.2"
root_servers = {}
root_servers["."] = "icann"
timeout_seconds = 7
hide_disclaimer = "YES"
sredniczarny:/home/baryluk/Dane/linux/maradns-dos/maradns-1.4.03#



Regards,
Witek

-- 
Witold Baryluk
JID: witold.baryluk // jabster.pl
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Kai Hendry <hendry@iki.fi>:
Bug#610834; Package maradns. (Mon, 24 Jan 2011 02:21:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to "Witold Baryluk" <baryluk@smp.if.uj.edu.pl>:
Extra info received and forwarded to list. Copy sent to Kai Hendry <hendry@iki.fi>. (Mon, 24 Jan 2011 02:21:03 GMT) Full text and rfc822 format available.

Message #18 received at 610834@bugs.debian.org (full text, mbox):

From: "Witold Baryluk" <baryluk@smp.if.uj.edu.pl>
To: 610834@bugs.debian.org
Subject: Additional info
Date: Mon, 24 Jan 2011 03:17:33 +0100
[Message part 1 (text/plain, inline)]
Forgot to add, that I send only single one query to resolver:

$ host w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.pl 127.0.0.1

Resolver properly returned response with A record,
but host utility timeouts for some reason (it probably sends MX query subsequntyl).

From valgrind report it looks that problem is in domain name / label compression code.

By they way, in past there was very similar problem was CVE-2002-2097, which also
was a bug in compression code in maradns.

-- 
Witold Baryluk
JID: witold.baryluk // jabster.pl
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Kai Hendry <hendry@iki.fi>:
Bug#610834; Package maradns. (Mon, 24 Jan 2011 04:39:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to "Witold Baryluk" <baryluk@smp.if.uj.edu.pl>:
Extra info received and forwarded to list. Copy sent to Kai Hendry <hendry@iki.fi>. (Mon, 24 Jan 2011 04:39:03 GMT) Full text and rfc822 format available.

Message #23 received at 610834@bugs.debian.org (full text, mbox):

From: "Witold Baryluk" <baryluk@smp.if.uj.edu.pl>
To: 610834@bugs.debian.org
Subject: Additional information about crash
Date: Mon, 24 Jan 2011 05:36:25 +0100
[Message part 1 (text/plain, inline)]
Additional information, about crash.

Crash seems to happen only when asking for AAAA RR type.

it happens when constructing NXDOMAIN response for AAAA query,
so given name do not need to exist in in DNS.


I will use python shorthands to construct queries.

$ /etc/init.d/maradns restart
$ host -t AAAA `python -c 'print "w."*124 + "pl"'`   # 250 characters (including dots), 125 labels, 252 octets at wire level
w.w.w ...  has no AAAA record
$ host -t AAAA `python -c 'print "w."*124 + "pl"'`
w.w.w ...  has no AAAA record
# maradns still is alive here, and I can repedetly query it for above address, but it already is in bad state
$ host -t AAAA ipv6.onet.pl  # irrelevant query
;; connection timed out; no servers could be reached
$ # (maradns crashed)

Interesingly if I ask for example for host -t A wp.pl, it do not crashes maradns.


$ /etc/init.d/maradns restart
$ host -t AAAA `python -c 'print "w."*123 + "o.pl"'`          # 250 characters (including dots), 125 labels, 252 octets at wire level
;; connection timed out; no servers could be reached
$
	

# 246 characters, 123 labels, 248 octets at wire level
$ /etc/init.d/maradns restart
$ host -v -t AAAA `python -c 'print "w."*121 + "o.pl"'`
$ host -v -t AAAA w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.o.pl

All above queries make maradns crash or start behaving in unstable way
(it crashes after some other query).

This is also legal query (254 octets)	, but makes maradns even strange thing:

$ /etc/init.d/maradns restart
$ host -v -t AAAA `python -c 'print "w."*125 + "pl"'`
;; Warning: Message parser reports malformed message packet.
;; Warning: Message parser reports malformed message packet.
Host w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.pl not found: 2(SERVFAIL)
$

This would be biggest possible query (255 octets)

$ /etc/init.d/maradns restart
$ host -t AAAA `python -c 'print "ww." + "w."*124 + "pl"'`
;; Warning: Message parser reports malformed message packet.
;; Warning: Message parser reports malformed message packet.
Host ww.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.pl not found: 2(SERVFAIL)
$

Maradns do not crash after both above queries, but memory coruption is obviously presents.



This query would be too large, according to host utility
$ host -v -t AAAA `python -c 'print "w."*126 + "pl"'`
host: 'w.w.w.REMOVED.w.w.w.w.pl' is not a legal name (ran out of space)
Exit 1
$


According to RFC 1035, section 2.3.4 a size limit is:

    labels          63 octets or less                      [ also know as component here ]
    names           255 octets or less


For messages a domain name is restricted in section 3.1

    To simplify implementations, the total length of a domain name (i.e.,
    label octets and label length octets) is restricted to 255 octets or
    less.


    [ PS. This do not say if this is restriction before or after compression/decompression.
          But because compression can only be performed for suffixes seen previously in
          the packet, our query do not compress at all (see section 4.1.4).
          But I will assume that becuase of "simplify implementation" it means "after decompression".
          Maybe some other rfc fixes this.
          Similary one can construct 'more' not-compressible query, like: "a.b.c.d.e......z.A.B....Z.0.1....9....pl"
          but unfortunelty in this way only 62 components can be constructed.
    ]

So it looks that considering also section 4.1.2, host utility properly reports when query is too large.

As each 'label length octets' eat 1 byte, I assume that 

"w."*124 + "pl"

is 2*124 + 2 = 250 characters as dot notation, but

is actually
   (1 length octet, 1 'w' characters)*124 + length octet + 2 characters for 'pl' + 1 length octet + 0 characters =
   (1+1)*124 + 1 + 2 + 1 =
   252 octets at wire level,
which looks ok.


Using ".w"*125, will give us 254 octets which still is OK.

I also tested different letters in domain name.

> A=map(chr, range(ord('a'), ord('z')+1) + range(ord('A'), ord('Z')+1) + range(ord('0'), ord('9')+1))
> print ".".join(A+A) + ".pl"
a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.q.r.s.t.u.v.w.x.y.z.A.B.C.D.E.F.G.H.I.J.K.L.M.N.O.P.Q.R.S.T.U.V.W.X.Y.Z.0.1.2.3.4.5.6.7.8.9.a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.q.r.s.t.u.v.w.x.y.z.A.B.C.D.E.F.G.H.I.J.K.L.M.N.O.P.Q.R.S.T.U.V.W.X.Y.Z.0.1.2.3.4.5.6.7.8.9.pl

124 components + 1 last component (pl) + 1 empty component (root domain).

It is very strange. When quering this (call it L1), maradns do not crash and returns NXDOMAIN (for AAAA).

If i change last 9, to "w"  (call this L2), maradns also do not crash and returns NXDOMIN (for AAAA).

But. If I query L1, and then L2, then maradns crashes. Also changing order makes crash.
Probably some obscure memory coruption.


I do not yet tested if this bug also happen if given AAAA query would resolve to existing AAAA RR.
(I assume I will need to install BIND and create fake nameserver to be sure).

I performed tests multiple times to make sure that other programs on the system performing
resolving do not interfere.

PS. Previous timeout was indeed happening due to the subsequent MX query by host utility.
It do not happen if specific RR type is asked using -t AAAA.

Regards,
-- 
Witold Baryluk
JID: witold.baryluk // jabster.pl
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Kai Hendry <hendry@iki.fi>:
Bug#610834; Package maradns. (Mon, 24 Jan 2011 05:03:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to "Witold Baryluk" <baryluk@smp.if.uj.edu.pl>:
Extra info received and forwarded to list. Copy sent to Kai Hendry <hendry@iki.fi>. (Mon, 24 Jan 2011 05:03:03 GMT) Full text and rfc822 format available.

Message #28 received at 610834@bugs.debian.org (full text, mbox):

From: "Witold Baryluk" <baryluk@smp.if.uj.edu.pl>
To: 610834@bugs.debian.org
Subject: Additional info, and possible fix
Date: Mon, 24 Jan 2011 05:59:33 +0100
[Message part 1 (text/plain, inline)]
I think that dns/Compress.c:90 should be changed from

    if((new->dlabel_points = js_alloc(MAX_DLABEL_POINTS + 3,1)) == 0) {

to

    if((new->dlabel_points = js_alloc(MAX_DLABEL_POINTS + 5,1)) == 0) {

or better (especially on 64 bit platforms!)

    if((new->dlabel_points = js_alloc(128 + 1,sizeof(int))) == 0) {


For complete view, there is currently
#define MAX_DLABEL_POINTS 512

but should IMHO be
#define MAX_DLABEL_POINTS 128


typedef struct compress_state {
 /// ....
    int *dlabel_points;
 // ...
} compress_state;


and place where crash happens


        /* Add the length to the dlabel_points array */
        state->dlabel_points[counter] = offset;
        state->dlabel_points[counter + 1] = 0;                         // line 200 of crash
        counter++;
        if(len == 0 || len > 63) {

This crashes obviously, becuase counter+1, will be 129 in our situation,
which will dereference 4 bytes from position 512, which includes byte 515 (counting from 0),
but last valid poistion is 514 (becuase allocated are have 515 bytes).

Actually similar problem exists few lines befor it:

    counter = 0;
    while(state->dlabel_points[counter] != 0 &&
          counter < MAX_DLABEL_POINTS - 10) {
        counter++;
        }

It is simply WRONG. if MAX_DLABEL_POINTS == 512, then it should be:

          sizeof(int)*counter < MAX_DLABEL_POINTS - 10) {

or just redefine MAX_DLABEL_POINTS properly to 128.

I also do not exactly understand why there is "- 10" part.

Main reason for this error (beyond obvious coding errors),
is that memory was allocated using js_alloc, not js_create,
which adds additional 3*size_unit bytes after allocated area, just to be sure.
(imho it should be even extended to check if this area have the same content on deallocation,
as it had on allocation).


Regards,
Witek


-- 
Witold Baryluk
JID: witold.baryluk // jabster.pl
[signature.asc (application/pgp-signature, inline)]

Message sent on to "Witold Baryluk" <baryluk@smp.if.uj.edu.pl>:
Bug#610834. (Mon, 24 Jan 2011 18:42:09 GMT) Full text and rfc822 format available.

Message #31 received at 610834-submitter@bugs.debian.org (full text, mbox):

From: Josh Bressers <bressers@redhat.com>
To: oss-security@lists.openwall.com, 610834-submitter@bugs.debian.org, maradns@gmail.com
Cc: coley <coley@mitre.org>
Subject: Re: [oss-security] CVE request: MaraDNS DoS via long queries
Date: Mon, 24 Jan 2011 13:38:07 -0500 (EST)
Please use CVE-2011-0520.

Thanks.

-- 
    JB


----- Original Message -----
> Hi,
> 
> A crash bug has been reported against MaraDNS 1.4.03 when long queries
> are
> sent to the resolver. Details can be found at:
> http://bugs.debian.org/610834
> 
> As of the time of writing, the reporter is testing other versions and
> at least
> 1.4.05 also seems to be affected.
> 
> Josh, Steven: could a CVE id be assigned? Thanks in advance.
> 
> Regards,
> --
> Raphael Geissert - Debian Developer
> www.debian.org - get.debian.net




Information forwarded to debian-bugs-dist@lists.debian.org, Kai Hendry <hendry@iki.fi>:
Bug#610834; Package maradns. (Sun, 30 Jan 2011 05:24:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Sam Trenholme <strenholme.usenet@gmail.com>:
Extra info received and forwarded to list. Copy sent to Kai Hendry <hendry@iki.fi>. (Sun, 30 Jan 2011 05:24:03 GMT) Full text and rfc822 format available.

Message #36 received at 610834@bugs.debian.org (full text, mbox):

From: Sam Trenholme <strenholme.usenet@gmail.com>
To: list@maradns.org
Cc: 610834@bugs.debian.org, geissert@debian.org, atomo64@gmail.com, bressers@redhat.com, coley@mitre.org, oss-security@lists.openwall.com
Subject: MaraDNS 1.4.06 and 1.3.07.11 released
Date: Sat, 29 Jan 2011 22:21:08 -0700
[Message part 1 (text/plain, inline)]
In 2002, when I rewrote the compression code for MaraDNS for the first
time, I made a mistake in allocating an array of integers, allocating
it in bytes instead of sizeof(int) units.  The resulted in a buffer
being too small, allowing it to be overwritten.

The impact of this programming error is that MaraDNS can be crashed by
sending MaraDNS a single "packet of death".  Since the data placed in
the overwritten array can not be remotely controlled (it is a list of
increasing integers), there is no way to increase privileges
exploiting this bug.

The attached patch resolves this issue by allocating in sizeof(int)
units instead of byte-sized units for an integer array.  In addition,
it uses a smaller array because a DNS name can only have, at most, 128
labels.

I would like to thank Mr. Witold Baryluk for pointing out this issue,
taking the time to backtrace the bug, and for bringing it to my
attention by posting to the MaraDNS mailing list.  However, I need to
let him know that making this public by filing a public Debian bug
without first trying to contact me is not the appropriate way to
handle a security problem with MaraDNS.  The appropriate way to do so
is via private email.  My email address is here:

http://samiam.org/mailme.php

(maradns@gmail.com was an account created so I could make entries in
an older MaraDNS blog, and is not presently actively looked at)

As it turns out, I only occasionally look at the Debian bug database
and people with issues with MaraDNS would be better off joining the
MaraDNS mailing list instead of filing a Debian bug (unless the issue
is Debian-specific).

In response to this bug, I have released MaraDNS 1.4.06 and 1.3.07.11.
 These releases are available here:

http://maradns.org/download.html

Since sourceforge.net has recently suffered a security breach, their
file uploading feature is currently undergoing maintenance and new
files currently can not be uploaded there.

I have not made a new release of MaraDNS 2.0 yet.  Yarin has
contributed a number of patches, and I would like to integrate his
patches before making a new MaraDNS 2.0 release; MaraDNS 2.0 users can
use the supplied patch.

As an aside, I have become a better programmer since making this
mistake back in 2002.  Deadwood, which is a complete rewrite of
MaraDNS' recursive code, does not have this issue in its
compression/decompression code.  Instead of using different data types
in structures, Deadwood, by and large, uses special overflow-resistant
strings to store most data.

Also, I would like to take the time to make a public service
announcement for djbdns users: DjbDNS 1.05 does have known security
issues, and needs to be patched.  More details are here:

http://samiam.org/blog/20110103.html

(I am making this announcement because I have seen people, as recently
as last year, claiming djbdns-1.05 is perfectly secure on public
forums)

- Sam

--- maradns-1.4.05/dns/Compress.c       2010-07-31 01:17:08.000000000 -0600
+++ maradns-1.4.06/dns/Compress.c       2011-01-28 18:28:46.000000000 -0700
@@ -22,7 +22,7 @@
 #include "functions_dns.h"

 /* Maximum allowed number of dlabel points */
-#define MAX_DLABEL_POINTS 512
+#define MAX_DLABEL_POINTS 160

 /* Maximum allowed length of compressed string; this is 4096 for TCP
  * packets */
@@ -87,7 +87,8 @@
         js_dealloc(new);
         return 0;
         }
-    if((new->dlabel_points = js_alloc(MAX_DLABEL_POINTS + 3,1)) == 0) {
+    if((new->dlabel_points = js_alloc(MAX_DLABEL_POINTS + 3,sizeof(int)))
+               == 0) {
         js_destroy(new->compressed);
         js_dealloc(new);
         return 0;
[maradns-1.4.05-CVE-2011-0520.patch (application/octet-stream, attachment)]

Reply sent to Moritz Muehlenhoff <jmm@debian.org>:
You have taken responsibility. (Sun, 30 Jan 2011 13:51:09 GMT) Full text and rfc822 format available.

Notification sent to "Witold Baryluk" <baryluk@smp.if.uj.edu.pl>:
Bug acknowledged by developer. (Sun, 30 Jan 2011 13:51:10 GMT) Full text and rfc822 format available.

Message #41 received at 610834-close@bugs.debian.org (full text, mbox):

From: Moritz Muehlenhoff <jmm@debian.org>
To: 610834-close@bugs.debian.org
Subject: Bug#610834: fixed in maradns 1.4.03-1.1
Date: Sun, 30 Jan 2011 13:47:09 +0000
Source: maradns
Source-Version: 1.4.03-1.1

We believe that the bug you reported is fixed in the latest version of
maradns, which is due to be installed in the Debian FTP archive:

maradns_1.4.03-1.1.diff.gz
  to main/m/maradns/maradns_1.4.03-1.1.diff.gz
maradns_1.4.03-1.1.dsc
  to main/m/maradns/maradns_1.4.03-1.1.dsc
maradns_1.4.03-1.1_amd64.deb
  to main/m/maradns/maradns_1.4.03-1.1_amd64.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 610834@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Moritz Muehlenhoff <jmm@debian.org> (supplier of updated maradns package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Sun, 30 Jan 2011 14:36:36 +0100
Source: maradns
Binary: maradns
Architecture: source amd64
Version: 1.4.03-1.1
Distribution: unstable
Urgency: high
Maintainer: Kai Hendry <hendry@iki.fi>
Changed-By: Moritz Muehlenhoff <jmm@debian.org>
Description: 
 maradns    - Simple security-focused Domain Name Service server
Closes: 610834
Changes: 
 maradns (1.4.03-1.1) unstable; urgency=high
 .
   * Non-maintainer upload by the Security Team
   * Fix CVE-2011-0520 (Closes: #610834)
Checksums-Sha1: 
 e472b5e403d60110fb5e57c11c2f3feacee5fd34 991 maradns_1.4.03-1.1.dsc
 e2eb8dcc1545876a36a2fd9f758e4cc7f503aeda 23776 maradns_1.4.03-1.1.diff.gz
 02f0a96020b428dc2404ca13f7412ad90b90dd6a 1363600 maradns_1.4.03-1.1_amd64.deb
Checksums-Sha256: 
 13575e4b0231e70736dab972e6bb013fcf31c161ee0891a6501c1a06ce00c601 991 maradns_1.4.03-1.1.dsc
 94661ca07bc867ba169b5bde24efc686979866ca237174b851a8291aa4736553 23776 maradns_1.4.03-1.1.diff.gz
 06d96fd7e522920ad3ed1e3e3b7a8d3588fec7d11d0bff85ac34e2cbcde6fa08 1363600 maradns_1.4.03-1.1_amd64.deb
Files: 
 eeef8682c4c0f89dd4acacf9a7788be2 991 net extra maradns_1.4.03-1.1.dsc
 768fd8be0ade25981b24c81e237aa851 23776 net extra maradns_1.4.03-1.1.diff.gz
 c8e4117ded55eb9cf41dc34ab39e557a 1363600 net extra maradns_1.4.03-1.1_amd64.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAk1Fab0ACgkQXm3vHE4uyloghQCfSbCgPGnQxoxZtMEoy+4TEjM9
L9wAn3Y8T2+wYgPmLR6QntAL5LZxyN+t
=D27n
-----END PGP SIGNATURE-----





Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Wed, 02 Mar 2011 07:32:55 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Thu Apr 24 22:25:37 2014; Machine Name: buxtehude.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.