Bug#868561: knot-resolver 1.2.0-1 occasionally fails to reply correctly to DS queries
Package: knot-resolver Version: 1.2.0-1 Severity: important Dear Maintainer, Under circumstances, when a zone is not signed, knot-resolver responds to DS queries for a zone with SOA record of the zone in question instead of the SOA record of the parent zone. Sending wrong DS replies breaks DNSSEC validation. Reproducing is quite easy, with a clean installation and cache. Issuing an A query and then a DS query reproduces the bug. An example: # kdig a void.gr @localhost ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 65070 ;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 0 ;; QUESTION SECTION: ;; void.gr. IN A ;; ANSWER SECTION: void.gr.3600IN A 83.212.168.30 ;; Received 41 B ;; Time 2017-07-15 03:21:50 EEST ;; From ::1@53(UDP) in 444.8 ms # kdig ds void.gr @localhost ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 1335 ;; Flags: qr rd ra; QUERY: 1; ANSWER: 0; AUTHORITY: 1; ADDITIONAL: 0 ;; QUESTION SECTION: ;; void.gr. IN DS ;; AUTHORITY SECTION: void.gr.3600IN SOA empty.void.gr. dnsmaster.void.gr. 2017071401 10800 3600 604800 10800 ;; Received 77 B ;; Time 2017-07-15 03:21:57 EEST ;; From ::1@53(UDP) in 64.4 ms Another example: # kdig a google.com @localhost ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 14794 ;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 0 ;; QUESTION SECTION: ;; google.com. IN A ;; ANSWER SECTION: google.com. 300 IN A 216.58.205.46 ;; Received 44 B ;; Time 2017-07-15 03:29:13 EEST ;; From ::1@53(UDP) in 444.5 ms # kdig ds google.com @localhost ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 37953 ;; Flags: qr rd ra; QUERY: 1; ANSWER: 0; AUTHORITY: 1; ADDITIONAL: 0 ;; QUESTION SECTION: ;; google.com. IN DS ;; AUTHORITY SECTION: google.com. 60 IN SOA ns2.google.com. dns-admin.google.com. 162019261 900 900 1800 60 ;; Received 78 B ;; Time 2017-07-15 03:29:17 EEST ;; From ::1@53(UDP) in 75.6 ms on knot-resolver from testing (1.3.0-2), the answers are correct: # dig a void.gr @localhost ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 56872 ;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 0 ;; QUESTION SECTION: ;; void.gr. IN A ;; ANSWER SECTION: void.gr.3600IN A 83.212.168.30 ;; Received 41 B ;; Time 2017-07-15 03:19:21 EEST ;; From ::1@53(UDP) in 441.5 ms # dig ds void.gr @localhost ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 32532 ;; Flags: qr rd ra; QUERY: 1; ANSWER: 0; AUTHORITY: 1; ADDITIONAL: 0 ;; QUESTION SECTION: ;; void.gr. IN DS ;; AUTHORITY SECTION: gr. 1800IN SOA grdns.ics.forth.gr. hmaster-info.ics.forth.gr. 1707142191 3600 180 5184000 1800 ;; Received 90 B ;; Time 2017-07-15 03:19:23 EEST ;; From ::1@53(UDP) in 52.8 ms # kdig a google.com @localhost ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 61740 ;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 0 ;; QUESTION SECTION: ;; google.com. IN A ;; ANSWER SECTION: google.com. 300 IN A 216.58.205.46 ;; Received 44 B ;; Time 2017-07-15 03:31:16 EEST ;; From ::1@53(UDP) in 805.4 ms # kdig ds google.com @localhost ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 27072 ;; Flags: qr rd ra; QUERY: 1; ANSWER: 0; AUTHORITY: 1; ADDITIONAL: 0 ;; QUESTION SECTION: ;; google.com. IN DS ;; AUTHORITY SECTION: com.900 IN SOA a.gtld-servers.net. nstld.verisign-grs.com. 1500078651 1800 900 604800 86400 ;; Received 104 B ;; Time 2017-07-15 03:31:21 EEST ;; From ::1@53(UDP) in 620.7 ms The order of queries matter # kdig ds google.com @localhost ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 55082 ;; Flags: qr rd ra; QUERY: 1; ANSWER: 0; AUTHORITY: 1; ADDITIONAL: 0 ;; QUESTION SECTION: ;; google.com. IN DS ;; AUTHORITY SECTION: com.900 IN SOA a.gtld-servers.net. nstld.verisign-grs.com. 1500078726 1800 900 604800 86400 ;; Received 104 B ;; Time 2017-07-15 03:32:23 EEST ;; From ::1@53(UDP) in 722.7 ms # kdig a google.com @localhost ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 16742 ;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY:
Bug#849747: bpfcc-tools needs different compile flags to work
Hello, it's actually a stretch/sid chroot on a jessie host. inside the chroot # cat /etc/debian_version stretch/sid # apt-cache policy linux-libc-dev linux-libc-dev: Installed: 4.8.11-1 Candidate: 4.8.11-1 Version table: *** 4.8.11-1 500 500 http://ftp.de.debian.org/debian testing/main amd64 Packages 100 /var/lib/dpkg/status # apt-cache policy linux-headers-4.8.0-2-amd64 linux-headers-4.8.0-2-amd64: Installed: 4.8.11-1 Candidate: 4.8.11-1 Version table: *** 4.8.11-1 500 500 http://ftp.de.debian.org/debian testing/main amd64 Packages 100 /var/lib/dpkg/status Take a look at https://github.com/iovisor/bcc/issues/397
Bug#849747: bpfcc-tools needs different compile flags to work
Package: bpfcc-tools
Version: 0.2.0-1
Severity: grave
Tags: newcomer
Justification: renders package unusable
Dear Maintainer,
Trying to run binaries after installing bpfcc-tools ends up in an error like
the following:
# tcpconnect
In file included from :317:
:5:10: fatal error: './include/linux/kconfig.h' file not found
#include "./include/linux/kconfig.h"
^
1 error generated.
Traceback (most recent call last):
File "/usr/sbin/tcpconnect", line 207, in
b = BPF(text=bpf_text)
File "/usr/lib/python2.7/dist-packages/bcc/__init__.py", line 197, in __init__
raise Exception("Failed to compile BPF module %s" % src_file)
Exception: Failed to compile BPF module
The fix for this is already upstream and one needs to change the debian/rules
file:
- dh_auto_configure -- -DREVISION_LAST=$(UPSTREAM_VERSION)
-DREVISION=$(UPSTREAM_VERSION) -DLLVM_DEFINITIONS="-D_GNU_SOURCE
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS"
+ dh_auto_configure -- -DREVISION_LAST=$(UPSTREAM_VERSION)
-DREVISION=$(UPSTREAM_VERSION) -DLLVM_DEFINITIONS="-D_GNU_SOURCE
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS"
-DBCC_KERNEL_HAS_SOURCE_DIR=1
The fix is documented here:
https://github.com/dkronst/bcc/commit/3e2f9d9d6250d3f8a076bbf1a953cf4f0d21f75a
After applying the change in debian/rules and rebuilding the package the
binaries work:
# tcpconnect
In file included from /virtual/main.c:3:
In file included from include/net/sock.h:51:
In file included from include/linux/netdevice.h:38:
In file included from include/linux/dmaengine.h:20:
In file included from include/linux/device.h:24:
In file included from include/linux/pinctrl/devinfo.h:21:
In file included from include/linux/pinctrl/consumer.h:17:
In file included from include/linux/seq_file.h:10:
include/linux/fs.h:2686:9: warning: comparison of unsigned enum
expression < 0 is always false [-Wtautological-compare]
if (id < 0 || id >= READING_MAX_ID)
~~ ^ ~
1 warning generated.
PIDCOMM IP SADDRDADDRDPORT
3805 Chrome_IOThr 4 10.20.10.1 1.2.3.4443
The following might also be a fix for the issue but I haven't tested it yet
https://github.com/iovisor/bcc/pull/701/files
-- System Information:
Debian Release: 8.6
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable'), (400, 'unstable'),
(400, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 4.8.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages bpfcc-tools depends on:
ii python-bpfcc0.2.0-1
ii python-netaddr 0.7.12-2
pn python:any
bpfcc-tools recommends no packages.
bpfcc-tools suggests no packages.
-- no debconf information
Bug#779197: linux-image-3.16.0-4-amd64: Guests running kernel =3.8 on a Wheezy host crash when connecting through qemu-kvm VNC port
Package: src:linux Version: 3.16.7-ckt4-3 Severity: important Tags: upstream Dear Maintainer, We have observed some strange behavior while dist-upgrading some of our VMs from wheezy to jessie kernels. Under certain circumstances the combination of a jessie guest on a wheezy host might lead to VM crashes while one is using the qemu-kvm VNC port. Steps to reproduce: 1. Wheezy host with kernel 3.2.0-4-amd64 2. Wheezy-bpo or Jessie KVM guest with kernel linux-image-3.16.0-4-amd64 3. Connect with a VNC client to the guest's KVM-VNC port 4. cat /dev/urandom while on VNC 5. Wait from a few seconds to 2-3 minutes and then the OS inside the VM crashes. The KVM process is still running but the KVM socket is not responding. The guest OS is inaccessible and the vm (after a restart) shows no signs of having crashed. We have done testing with various Debian kernels as both host and guest and also testing with other distributions as guests. Our tests so far have shown that on a host running a wheezy-bpo/jessie kernel the crash does not appear to happen. We can reproduce the bug on Debian Jessie and Centos 7, but not on Ubuntu LTS or the latest GRML live cd. Here's a matrix of what works and what doesn't: HOST KERNEL | GUEST KERNEL | qemu-kvm version | Crash | Notes 3.2.63-2+deb7u1 | 3.2.65-1 | 1.1.2+dfsg-6+deb7u4 | no | wheezy on wheezy 3.2.63-2+deb7u1 | 3.16.7-ckt4-3 | 1.1.2+dfsg-6+deb7u4 | YES | jessie on wheezy 3.2.63-2+deb7u1 | 3.10.0-123.20.1.el7.x86_64 | 1.1.2+dfsg-6+deb7u4 | YES | centos7 on wheezy 3.2.63-2+deb7u2 | 3.2.65-1 | 2.0.0+dfsg-4~bpo70+1 | no | wheezy on wheezy with KVM from bpo 3.2.63-2+deb7u2 | 3.16.7-ckt4-3 | 2.0.0+dfsg-4~bpo70+1 | YES | jessie on wheezy with KVM from bpo 3.2.65-1 | 3.16.7-ckt4-3~bpo70+1 | 1.1.2+dfsg-6+deb7u6 | YES | wheezy-bpo on wheezy 3.16.7-ckt4-3~bpo70+1 | 3.16.7-ckt4-3~bpo70+1 | 1.1.2+dfsg-6+deb7u6 | no | wheezy-bpo on wheezy-bpo 3.2.63-2+deb7u2 | 2.6.32-504.8.1.el6.x86_64 | 2.0.0+dfsg-4~bpo70+1 | no | centos6 on wheezy 3.2.63-2+deb7u2 | 2.6.32-5 | 2.0.0+dfsg-4~bpo70+1 | no | squeeze on wheezy with KVM from bpo 3.16.7-ckt2-1 | 3.2.65-1+deb7u1| 2.1+dfsg-11 | no | wheezy on jessie 3.2.63-2+deb7u2 | 3.13.0-39-generic | 2.0.0+dfsg-4~bpo70+1 | no | ubuntu 14.04 on wheezy with KVM from bpo 3.2.63-2+deb7u2 | 3.16.7-1+grml.1| 2.0.0+dfsg-4~bpo70+1 | no | grml on wheezy with KVM from bpo 3.2.65-1 | 3.4-trunk-amd64| 1.1.2+dfsg-6+deb7u6 | no | wheezy 3.4 trunk on wheezy 3.2.65-1 | 3.6-trunk-amd64| 1.1.2+dfsg-6+deb7u6 | no | wheezy 3.6 trunk on wheezy 3.2.65-1 | 3.7-trunk-amd64| 1.1.2+dfsg-6+deb7u6 | no | wheezy 3.7 trunk on wheezy 3.2.65-1 | 3.8-trunk-amd64| 1.1.2+dfsg-6+deb7u6 | YES | wheezy 3.8 trunk on wheezy From our tests the problem first appears when the guest uses kernel 3.8-trunk-amd64. Testing with different qemu-kvm versions has shown that no direct relation exists. -- Package-specific info: ** Version: Linux version 3.16.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt4-3 (2015-02-03) ** Command line: root=/dev/vda3 ro ** Not tainted ** Kernel log: [0.822291] virtio-pci :00:05.0: irq 44 for MSI/MSI-X [0.896563] ata2.01: NODEV after polling detection [0.897094] ata2.00: ATAPI: QEMU DVD-ROM, 1.1.2, max UDMA/100 [0.898478] ata2.00: configured for MWDMA2 [0.900231] scsi 1:0:0:0: CD-ROMQEMU QEMU DVD-ROM 1.1. PQ: 0 ANSI: 5 [0.921570] sr0: scsi3-mmc drive: 4x/4x cd/rw xa/form2 tray [0.922599] cdrom: Uniform CD-ROM driver Revision: 3.20 [0.924093] sr 1:0:0:0: Attached scsi CD-ROM sr0 [0.926157] sr 1:0:0:0: Attached scsi generic sg0 type 5 [0.939244] vda: vda1 vda2 vda3 [1.036190] usb 1-1: new full-speed USB device number 2 using uhci_hcd [1.453028] usb 1-1: New USB device found, idVendor=0627, idProduct=0001 [1.453815] usb 1-1: New USB device strings: Mfr=1, Product=3, SerialNumber=5 [1.454508] usb 1-1: Product: QEMU USB Tablet [1.455104] usb 1-1: Manufacturer: QEMU 1.1.2 [1.455684] usb 1-1: SerialNumber: 42 [1.466088] hidraw: raw HID events driver (C) Jiri Kosina [1.477309] usbcore: registered new interface driver usbhid [1.477943] usbhid: USB HID core driver [1.482236] input: QEMU 1.1.2 QEMU USB Tablet as /devices/pci:00/:00:01.2/usb1/1-1/1-1:1.0/0003:0627:0001.0001/input/input2 [1.483794] hid-generic 0003:0627:0001.0001: input,hidraw0: USB HID v0.01 Pointer [QEMU 1.1.2 QEMU USB Tablet] on usb-:00:01.2-1/input0 [1.568374] tsc: Refined TSC clocksource calibration:
Bug#747230: Acknowledgement (opendnssec-signer: segfaults if NotifyCommand fails when adding a new zone)
Further debugging showed that the original bug report was flawed.
The problem was actually caused by
https://issues.opendnssec.org/browse/OPENDNSSEC-285
The bug has been fixed upstream in 1.3.10.
The following patch applies cleanly to 1.3.9-5 of current stable
release.
--- a/signer/src/signer/signconf.c 2014-05-08 12:58:54.0 +0300
+++ b/signer/src/signer/signconf.c 2014-05-08 12:59:12.0 +0300
@@ -179,7 +179,7 @@
st_mtime = ods_file_lastmodified(scfile);
if (st_mtime = last_modified) {
ods_log_deeebug([%s] file %s not modified since (file %u,
-mem %u), sc_str, (unsigned) st_mtime,
+mem %u), sc_str, scfile, (unsigned) st_mtime,
(unsigned) last_modified);
return ODS_STATUS_UNCHANGED;
}
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#747230: opendnssec-signer: segfaults if NotifyCommand fails when adding a new zone
Package: opendnssec-signer Version: 1:1.3.9-5 Severity: normal Tags: upstream Dear Maintainer, There's a condition that leads to a segfault of ods-signerd. If you set up a NotifyCommand in the form of: NotifyCommand/usr/sbin/rndc reload %zone/NotifyCommand and you add a new zone to zonelist.xml but you have not added the zone to bind9, then the NotifyCommand returns with an error (1). If the zone in question hasn't been previously added in the past (there are no entries yet for it in signconf), then ods-signerd segfaults. May 6 16:47:20 kernel: [345243.122129] ods-signerd[15978]: segfault at 5368e00d ip 7ff029561cba sp 7ff0266eb080 error 4 in libc-2.13.so[7ff02951c000+182000] at the /var/lib/opendnssec/unsigned directory one finds only the zone.name.axfr file of the new zone. while the segfault is actually caused by an administrator error (missing config parts in bind9 that leads to a rndc error) it would be nice if ods-signerd handled it a bit better. -- System Information: Debian Release: 7.5 APT prefers stable APT policy: (800, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=el_GR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages opendnssec-signer depends on: ii libc6 2.13-38+deb7u1 ii libldns1 1.6.13-1 ii libxml22.8.0+dfsg1-7+nmu3 ii opendnssec-common 1:1.3.9-5 Versions of packages opendnssec-signer recommends: ii opendnssec-auditor 1:1.3.9-5 ii opendnssec-enforcer 1:1.3.9-5 Versions of packages opendnssec-signer suggests: pn opendnssec none ii softhsm 1.3.3-2 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#719095: vzctl: ndsend uses wrong option type for Link-layer Address according to RFC4861
Package: vzctl Version: 3.0.30.2-4 Severity: important Tags: upstream patch ipv6 Dear Maintainer, ndsend which is contained in vzctl package comes with an important bug. According to RFC4861 #4.4 #4.6.1 when sending an unsolicited Neighbor Advertisement one should be using option type 2 (Target Link-Layer Address). ndsend on the other hand uses option type 1 (Source Link-Layer Address). This makes RFC compliant devices not behaving according to what ndsend is supposed to do, the packet is ignored. The simple attached patch fixes the above issue for ndsend. The patch applies to both stable (wheezy) and oldstable (squeeze) versions. -- System Information: Debian Release: 7.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=el_GR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages vzctl depends on: ii iproute 20120521-3+b3 ii libc62.13-38 ii vzquota 3.0.12-3 Versions of packages vzctl recommends: ii rsync 3.0.9-4 vzctl suggests no packages. -- George Kargiotakis --- a/src/ndsend.c 2013-08-08 14:49:14.0 +0300 +++ b/src/ndsend.c 2013-08-08 14:49:23.0 +0300 @@ -93,7 +93,7 @@ pkt-router = 0; pkt-reserved = 0; memcpy(pkt-target, src_ipaddr, 16); - pkt-otype = ND_OPT_SOURCE_LINKADDR; + pkt-otype = ND_OPT_TARGET_LINKADDR; pkt-ospace = 1; memcpy(pkt-obits, real_hwaddr, 6); }
Bug#701703: opendnssec package is not including proper build dependencies (missing procps/psmisc)
Package: opendnssec Version: 1:1.3.9-2 Severity: important opendnssec build dependencies do not include procps or psmisc. procps provides 'pkill' and psmisc provides 'killall'. Either of those is needed by ods-ksmutil to send HUP signal to ods-enforcerd. The configure script searches for either of these to set 'RESTART_ENFORCERD_CMD' definition. If the configure script doesn't find 'pkill' or 'killall' it sets RESTART_ENFORCERD_CMD to '/bin/false' which makes opendnssec unusable as it needs manual intervention to perform the HUP of ods-enforcerd. Example: # ods-ksmutil key rollover --zone example.net --keytype ZSK Could not HUP ods-enforcerd Please add procps as build dependency to opendnssec. -- System Information: Debian Release: 6.0.7 APT prefers stable APT policy: (800, 'stable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=el_GR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages opendnssec depends on: ii libhsm-bin1:1.3.9-2 library for interfacing PKCS#11 Ha ii opendnssec-common 1:1.3.9-2 common configuration files for Ope ii opendnssec-enforcer 1.1.3-3tool to prepares DNSSEC keys (comm ii opendnssec-enforcer-sqlite3 1:1.3.9-2 tool to prepare DNSSEC keys (sqlit ii opendnssec-signer 1:1.3.9-2 daemon to sign DNS zone files peri Versions of packages opendnssec recommends: ii opendnssec-auditor1:1.3.9-2 tool to audit DNS signed zones acc Versions of packages opendnssec suggests: ii softhsm 1.3.3-2a cryptographic store accessible t -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#681677: opendnssec patch
The fix is as simple as replacing a single character. Somebody please merge that fix/patch. --- debian/patches/009-ods-control.in_fixes.patch 2013-02-22 12:02:44.0 +0200 +++ debian/patches/009-ods-control.in_fixes.patch 2013-02-22 12:02:58.0 +0200 @@ -37,7 +37,7 @@ $0 enforcer stop echo Stopping signer engine... - $sbindir/ods-signer stop -+ $0 signed stop ++ $0 signer stop + exit $? ;; -- Γιώργος Καργιωτάκης kar...@noc.grnet.gr Κέντρο Διαχείρισης Δικτύου Εθνικό Δίκτυο Έρευνας και Τεχνολογίας - http://www.grnet.gr Τηλέφωνο: +30 2107475711Fax: +30 2107474490 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#672859: wwsympa.fcgi fails to check download/delete permissions properly
Package: sympa
Version: 6.0.1+dfsg-4
Severity: grave
Sympa versions 6.1.11 have a severe security issue where any user can
download or delete the archives of a mailing list if they know the name
of the list.
Debian has been tracking it at
http://security-tracker.debian.org/tracker/CVE-2012-2352
I'm attaching a patch (taken from upstream commit:
https://sourcesup.renater.fr/scm/viewvc.php/branches/sympa-6.0-branch/wwsympa/wwsympa.fcgi.in?root=sympapathrev=7358
) that fixes the problem
-- System Information:
Debian Release: 6.0.4
APT prefers stable
APT policy: (800, 'stable'), (650, 'testing'), (500, 'stable-updates')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=el_GR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--- wwsympa.fcgi2012-05-14 11:53:36.0 +0300
+++ wwsympa.fcgi2012-05-14 11:55:09.0 +0300
@@ -15956,6 +15956,11 @@
sub do_arc_manage {
wwslog('info', do_arc_manage ($in{'list'}));
+ ## Access Control
+ unless (defined check_authz('do_arc', 'web_archive.access')) {
+ return undef;
+ }
+
my $search_base = $wwsconf-{'arc_path'}.'/'.$list-get_list_id();
opendir ARC, $search_base;
foreach my $dir (sort {$b cmp $a} grep(!/^\./,readdir ARC)) {
@@ -15972,6 +15977,11 @@
sub do_arc_download {
wwslog('info', do_arc_download ($in{'list'}));
+
+ ## Access Control
+ unless (defined check_authz('do_arc', 'web_archive.access')) {
+ return undef;
+ }
##zip file name:listname_archives.zip
my $zip_file_name = $in{'list'}.'_archives.zip';
@@ -16072,6 +16082,11 @@
my @abs_dirs;
wwslog('info', do_arc_delete ($in{'list'}));
+
+ ## Access Control
+ unless (defined check_authz('do_arc', 'web_archive.access')) {
+ return undef;
+ }
unless (defined $in{'directories'}){
report::reject_report_web('user','select_month',{},$param-{'action'});
