gnash creates world-readable cookies under /tmp
Package: gnash Version: 0.8.10~git20111001-1 Tags: security Severity: critical Justification: Introduces a new security hole Hi, after watching videos on YouTube I found this in /tmp: $ ls -l /tmp/gnash* -rw-r--r-- 1 alexander alexander 329 Nov 20 15:22 /tmp/gnash-cookies.31032 $ Please note that the file is world-readable. This enables things like: $ sudo -u nobody cat /tmp/gnash-cookies.31032 Set-Cookie: use_hitbox=72c46ff6cbcdb7c5585c36411b6b334edAEw Set-Cookie: VISITOR_INFO1_LIVE=WEbeevRfDNo Set-Cookie: recently_watched_video_id_list=885d7cf2658d586fc1bef37a995ce29cWwEAAABzCwAAAHV3SFIwM1pHd1k4 Set-Cookie: GEO=0bf89ff87b12d82d91e10ddf1da36d95cwszREVUmagnTskNGQ== Set-Cookie: PREF=f1=4000fv=10.1.999 $ Since gnash is installed per default and also starts playing as soon as flash content is detected, this can be a serious security/privacy issue on multi-user systems. Gnash should either use $HOME for storing cookies or create them with sane permissions (0600). Best regards Alexander Kurtz signature.asc Description: This is a digitally signed message part
Re: Bug#649384: gnash creates world-readable cookies under /tmp
retitle 649384 gnash creates world-readable cookies under /tmp with predictable filenames thanks On Sun, 2011-11-20 at 18:01 +0100, Gabriele Giacone wrote: tags 649384 fixed-upstream thanks On Sun, Nov 20, 2011 at 03:39:36PM +0100, Alexander Kurtz wrote: or create them with sane permissions (0600). http://git.savannah.gnu.org/gitweb/?p=gnash.git;a=commitdiff;h=fa481c116e65ccf9137c7ddc8abc3cf05dc12f55 I don't think this fixes the underlying problem: An attacker would still be able to read the cookie if he managed to win the race-condition and opens the file before the chmod(). If you agree, please remove the fixed-upstream tag. Furthermore, I took a quick look at the code and noticed this: 1105 gnash::log_debug(The Cookie for %s is %s, url, ncookie); 1106 std::ofstream cookiefile; 1107 std::stringstream ss; 1108 ss /tmp/gnash-cookies. getpid(); 1109 1110 cookiefile.open(ss.str().c_str(), std::ios::out | std::ios::trunc); chmod (ss.str().c_str(), 0600); I might be wrong, but I very strongly suspect a possible symlink attack here which would enable an attacker to overwrite arbitrary files and (with your patch) change their permissions. Best regards Alexander Kurtz signature.asc Description: This is a digitally signed message part
Re: upower: resets block-device tunings on startup
tags 625606 security thanks Hi, this bug introduces a new security hole, consider the following example: # cat /etc/fstab [...] /home /mnt none bind 0 0 /home /mnt none bind,remount,ro 0 0 # mount -v -a [...] /home on /mnt type none (rw,bind) /home on /mnt type none (ro,bind) # mount | grep /mnt /home on /mnt type none (ro,bind) # pm-powersave true # mount | grep /mnt /home on /mnt type none (rw,bind,commit=600) Notice how calling pm-powersave changes the mount options from read-only to read-write. Since I'm actually using something like this on a server to deliver read-only backups, this bug is quite serious for me. The actual problem here is that /usr/lib/pm-utils/power.d/journal-commit calls mount -o remount,commit=600 /mnt in line 27 which overwrites the previous mount options: # mount -v -a [...] /home on /mnt type none (rw,bind) /home on /mnt type none (ro,bind) # mount | grep /mnt /home on /mnt type none (ro,bind) # mount -o remount,commit=600 /mnt/ # mount | grep /mnt /home on /mnt type none (rw,bind,commit=600) Since that bug now makes unrelated software on the system break AND introduces a security hole on systems where you install the package can we please raise the severity back to critical again? Best regards Alexander Kurtz signature.asc Description: This is a digitally signed message part
Re: schroedinger: Generates a 500M build log
Hi, what are the chances of #599095 being fixed soon? This bug currently blocks VLC[1][2] from migrating to testing which would fix some important security issues[3][4] (DSA 2211-1 [5]). Best regards Alexander Kurtz [1] http://release.debian.org/migration/testing.pl?package=vlc [2] https://buildd.debian.org/status/package.php?p=vlc [3] http://security-tracker.debian.org/tracker/CVE-2010-3275 [4] http://security-tracker.debian.org/tracker/CVE-2010-3276 [5] http://lists.debian.org/debian-security-announce/2011/msg00080.html signature.asc Description: This is a digitally signed message part
Re: Bug#614785: Found too in oldstable/lenny?
Hi everybody, Am Mittwoch, den 23.02.2011, 16:13 +0100 schrieb Michael Biebl: A fixed package has been uploaded to unstable and stable-security (squeeze). First the good news: I can confirm that upgrading *all* avahi packages to 0.6.28-4 fixes the problem (only upgrading avahi-daemon does not!). Am Donnerstag, den 24.02.2011, 13:27 +0100 schrieb Salvatore Bonaccorso: I can reproduce this too on lenny, can someone confirm that? Up to date lenny system with avahi-daemon 0.6.23-3lenny2. Now the bad news: The Debian security tracker[1] says: [lenny] - avahi not-affected (Vulnerable code not present, introduced in 0.6.25) That's wrong: Looking at the source code reveals this: $ cat avahi-0.6.23/debian/patches/15_CVE-2010-2244.patch --- a/avahi-core/socket.c +++ avahi-0.6.23/avahi-core/socket.c @@ -652,6 +652,10 @@ AvahiDnsPacket *avahi_recv_dns_packet_ipv4( goto fail; } +/* corrupt packets have zero size */ +if (!ms) +goto fail; + p = avahi_dns_packet_new(ms + AVAHI_DNS_PACKET_EXTRA_SIZE); io.iov_base = AVAHI_DNS_PACKET_DATA(p); @@ -805,6 +809,10 @@ AvahiDnsPacket *avahi_recv_dns_packet_ipv6( goto fail; } +/* corrupt packets have zero size */ +if (!ms) +goto fail; + p = avahi_dns_packet_new(ms + AVAHI_DNS_PACKET_EXTRA_SIZE); io.iov_base = AVAHI_DNS_PACKET_DATA(p); $ So, the code which introduced this vulnerability (CVE-2011-1002[1]) was actually added[2] when fixing another vulnerability (CVE-2010-2244[3]). As a consequence, lenny IS indeed vulnerable and needs to be fixed too. Best regards and thank you very much for your work! Alexander Kurtz [1] http://security-tracker.debian.org/tracker/CVE-2011-1002 [2] http://packages.qa.debian.org/a/avahi/news/20100805T140231Z.html [3] http://security-tracker.debian.org/tracker/CVE-2010-2244 signature.asc Description: This is a digitally signed message part
Re: Bug#614785: Found too in oldstable/lenny?
Am Donnerstag, den 24.02.2011, 15:57 +0100 schrieb Michael Biebl: But you are right, the security tracker should be updated http://svn.debian.org/wsvn/secure-testing/?rev=16247 Best regards Alexander Kurtz signature.asc Description: This is a digitally signed message part
avahi-daemon uses 100% of cpu when scanned with nmap (DoS possible?)
Package: avahi-daemon Version: 0.6.27-2 Tags: security Severity: critical Justification: Introduces possible denial-of-service scenario. Hi, when I scan my server from another machine on the network using nmap, I get this: # nmap -sU -p5353 192.168.2.2 Starting Nmap 5.00 ( http://nmap.org ) at 2011-02-23 13:15 CET Interesting ports on 192.168.2.2: PORT STATE SERVICE 5353/udp open|filtered zeroconf MAC Address: XX:XX:XX:XX:XX:XX (Netgear) Nmap done: 1 IP address (1 host up) scanned in 0.50 seconds # As soon as the scan starts, avahi-daemon on the server starts running amok, top shows this: PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 5535 avahi 20 0 33884 1600 1280 R 100 0.0 2:28.47 avahi-daemon Restarting avahi-daemon is not possible: # /etc/init.d/avahi-daemon restart Restarting Avahi mDNS/DNS-SD Daemon: avahi-daemonFailed to kill daemon: Timer expired . # Simply terminating the process doesn't work either: # ps -Af | grep avahi-daemon avahi 5535 1 87 13:14 ?00:04:43 avahi-daemon: running [server.local] avahi 5536 5535 0 13:14 ?00:00:00 avahi-daemon: chroot helper root 5610 5581 0 13:20 pts/200:00:00 grep avahi-daemon # kill 5535 # ps -Af | grep avahi-daemon avahi 5535 1 88 13:14 ?00:05:02 avahi-daemon: running [server.local] avahi 5536 5535 0 13:14 ?00:00:00 avahi-daemon: chroot helper root 5614 5581 0 13:20 pts/200:00:00 grep avahi-daemon # Forcibly killing the process works: # kill -9 5535 # ps -Af | grep avahi-daemon root 5629 5581 0 13:23 pts/200:00:00 grep avahi-daemon # I don't know what kind of data nmap sends when scanning for open UDP ports, but it definitely shouldn't cause avahi-daemon to run amok. Please note that I have not changed the Avahi configuration in any way, so you should be able to reproduce this easily. Please tell me if you need any more information! Best regards Alexander Kurtz signature.asc Description: This is a digitally signed message part
sudo doesn't ask for password when only the GID is changed
Package: sudo Version: 1.7.4p4-2 Severity: important Tags: security Hi, normally sudo doesn't allow to change the GID only: $ sudo -g staff id Sorry, user alexander is not allowed to execute '/usr/bin/id' as alexander:staff on alexander. $ The solution for this is to change the %sudo entry in /etc/sudoers like this: %sudo ALL=(ALL:ALL) ALL This line has been the default in sid for over a month now (see #602699[1]). However the above line seems to have some serious, unwanted side-effects: If you normally use sudo, you're asked to re-authenticate yourself, typically via password: $ sudo -u root id [sudo] password for alexander: uid=0(root) gid=0(root) groups=0(root) But if you only want to change the GID, sudo DOES NOT ask for a password, even not if you explicitly reset the time stamp: $ sudo -g staff id uid=1000(alexander) gid=50(staff) groups=1000(alexander),27(sudo),112(fuse) $ sudo -k $ sudo -g staff id uid=1000(alexander) gid=50(staff) groups=1000(alexander),27(sudo),112(fuse) IMHO this is a security issue[2], since it allows privilege escalation without asking for a password. Either this bug should be fixed[3] or sudo should stop asking for a password completely. The current behavior is inconsistent and violates the principle of least surprise. Best regards Alexander Kurtz [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=602699 [2] I chose Severity: important because the problem only occurs when you are a member of the sudo group. Please feel free to raise the severity if you think it is necessary. [3] Please note that simply reverting the fix for #602699 is NOT a solution! signature.asc Description: This is a digitally signed message part
libopensc: protect for possible buffer overflows from rogue cards.
Package: libopensc2 Version: 0.11.4-5+lenny1 Tags: security Severity: critical Hi, a buffer overflow vulnerability was detected in libopensc. For details please see this press article (German: [1], English: [2]) and the detailed report[3] including a proof-of-concept by MWR InfoSecurity[4]. The OpenSC developers have released a patch which should fix this vulnerability[5]. If Debian isn't affected by this vulnerability or if it has already been fixed, please don't hesitate to downgrade or close this bug. Best regards Alexander Kurtz [1] http://www.heise.de/security/meldung/Wenn-die-Smartcard-den-Rechner-rootet-1154599.html [2] http://www.h-online.com/open/news/item/When-a-smart-card-can-root-your-computer-1154829.html [3] http://labs.mwrinfosecurity.com/files/Advisories/mwri_opensc-get-serial-buffer-overflow_2010-12-13.pdf [4] http://www.mwrinfosecurity.com/index.php [5] https://www.opensc-project.org/opensc/changeset/4913 signature.asc Description: This is a digitally signed message part
Re: Re: mt-daapd #404640 introduces remote security hole
Cyril Brulebois k...@debian.org wrote YOU MUST BE KIDDING. No, I'm actually serious about my concerns, however since the package maintainer quickly responded to my bug report, I think it might be better to discuss the issue on #404640 and stop discussion here. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=404640 Thanks Alexander Kurtz signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
mt-daapd #404640 introduces remote security hole
Hi, since it took more than half a year until someone responded to the initial mail of #404640 and there are still SERIOUS REMOTE SECURITY ISSUES UNFIXED, I thougt I'd just drop a link: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=404640 Alexander Kurtz signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
