[Full-disclosure] rPSA-2008-0099-1 dbus dbus-glib dbus-qt dbus-x11
rPath Security Advisory: 2008-0099-1 Published: 2008-03-07 Products: rPath Linux 1 Rating: Minor Exposure Level Classification: Local System User Deterministic Privilege Escalation Updated Versions: [EMAIL PROTECTED]:1/0.50-2.4-1 [EMAIL PROTECTED]:1/0.50-2.4-1 [EMAIL PROTECTED]:1/0.50-2.4-1 [EMAIL PROTECTED]:1/0.50-2.4-1 rPath Issue Tracking System: https://issues.rpath.com/browse/RPL-2282 References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0595 Description: Previous versions of the dbus package are vulnerable to a Privilege Escalation attack in which local users may bypass security policies by using specifically crafted dbus method calls. http://wiki.rpath.com/Advisories:rPSA-2008-0099 Copyright 2008 rPath, Inc. This file is distributed under the terms of the MIT License. A copy is available at http://www.rpath.com/permanent/mit-license.html ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Firewire Attack on Windows Vista
> Yeah, I made specific reference to that attack in my message. There's a > big difference between sleep mode and hibernate mode. In hibernate the > system is powered off. Even if the memory has some residual charge I'm > sure it's far less reliable than with sleep. Yeah, but the whole point is if it's written to disk, the data is much easier to get at. The hard thing to do is steal memory. I've read that some HD encryption systems encrypt the hibernate file too, so perhaps you're better off in that situation. However, if the attacker anticipates this, he could simply power the system on, get the come-out-of-hibernation login prompt, compromise the kernel by injecting a driver or some such thing with a FireWire Memory attack, and then send it back into hibernate or something along those lines and wait for the real user to log in. I can't say that I keep up on the particulars of how Windows does this or that or the other related to hibernation and encryption, so perhaps the specific attack above is flawed, but if you get to physical memory and it's game over. Doesn't matter what you do with obfuscation around encryption. tim ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Firewire Attack on Windows Vista
>>The funniest is using hibernate... >>Did you perchance read: http://www.eff.org/press/archives/2008/02/21-0 ?? Yeah, I made specific reference to that attack in my message. There's a big difference between sleep mode and hibernate mode. In hibernate the system is powered off. Even if the memory has some residual charge I'm sure it's far less reliable than with sleep. Everything I've seen in descriptions of that attack tells me they are unfairly conflating sleep and hibernate. Larry Seltzer eWEEK.com Security Center Editor http://security.eweek.com/ http://blogs.pcmag.com/securitywatch/ Contributing Editor, PC Magazine [EMAIL PROTECTED] ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Firewire Attack on Windows Vista
Hi Larry, > - use drive > encryption, use 2-factor authentication, use hibernate instead of sleep, > use group policy to enforce them. Uh... yeah. So how again does drive encryption help you against this attack? Certain forms of 2-factor auth might help you, but all of the kinds I've seen would still rely on encryption keys in memory to encrypt any sensitive data on the drive, not to mention the fact that writing to memory would still bypass that auth. The funniest is using hibernate... Did you perchance read: http://www.eff.org/press/archives/2008/02/21-0 ?? Once again MS treats a security issue as a PR issue. > The fact that you can turn off DMA on Linux > seems in fact inferior to simply disabling the Firewire port and driver > at run-time in Windows. They both suck as solutions. How exactly is the Linux solution inferior? Not just trying to defend Linux and attack Windows here, but really I don't see how this statement is true, so you must not understand how it works. By disabling DMA, you're just disabling it for that one driver, not all drivers. In addition, you can load/unload driver modules at run-time typically. > Incidentally, Microsoft made a few other points in their response that > were interesting, but raised more questions than they answered: > > * it's possible for a user to disable 1394 DMA. I'm still looking into > how you can do this. That would be interesting to find out. Please do tell if you figure out how this can be done. > * it's possible for a user to "constrain a DMA device's memory access to > specific ranges by using the physical DMA type." They say that some > devices cannot be so restricted at all, and for others the restriction > would only come at the cost of additional complexity and a performance > hit, as I allude to above. I assume these considerations are generic to > the hardware and not specific to Windows. Ok, so they concede it is possible to limit the DMA accesses to specific (safe) ranges. I wonder which devices cannot be restricted... > How much should the average user worry about this? Not very much. Yeah, I agree it's probably not a big risk right now. That may change over time though, as more and more small devices become very programmable. You can already hack Linux onto your iPod, which makes a great cover for casually compromizing machines in an office environment. The number of small devices which would normally seem benign to end users, but are capable of being quite evil, will only increas over time. Good luck with your article, tim ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] [ GLSA 200803-14 ] Ghostscript: Buffer overflow
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Gentoo Linux Security Advisory GLSA 200803-14 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - http://security.gentoo.org/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Severity: Normal Title: Ghostscript: Buffer overflow Date: March 08, 2008 Bugs: #208999 ID: 200803-14 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Synopsis A stack-based buffer overflow has been discovered in Ghostscript, allowing arbitrary code execution. Background == Ghostscript is a suite of software based on an interpreter for PostScript and PDF. Affected packages = --- Package / Vulnerable / Unaffected --- 1 app-text/ghostscript-esp < 8.15.4-r1>= 8.15.4-r1 2 app-text/ghostscript-gpl < 8.61-r3 >= 8.61-r3 3 app-text/ghostscript-gnu < 8.60.0-r2>= 8.60.0-r2 --- 3 affected packages on all of their supported architectures. --- Description === Chris Evans (Google Security) discovered a stack-based buffer overflow within the zseticcspace() function in the file zicc.c when processing a PostScript file containing a long "Range" array in a .seticcscpate operator. Impact == A remote attacker could exploit this vulnerability by enticing a user to open a specially crafted PostScript file, which could possibly lead to the execution of arbitrary code or a Denial of Service. Workaround == There is no known workaround at this time. Resolution == All Ghostscript ESP users should upgrade to the latest version: # emerge --sync # emerge --ask --oneshot --verbose ">=app-text/ghostscript-esp-8.15.4-r1" All Ghostscript GPL users should upgrade to the latest version: # emerge --sync # emerge --ask --oneshot --verbose ">=app-text/ghostscript-gpl-8.61-r3" All Ghostscript GNU users should upgrade to the latest version: # emerge --sync # emerge --ask --oneshot --verbose ">=app-text/ghostscript-gnu-8.60.0-r2" References == [ 1 ] CVE-2008-0411 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0411 Availability This GLSA and any updates to it are available for viewing at the Gentoo Security Website: http://security.gentoo.org/glsa/glsa-200803-14.xml Concerns? = Security is a primary focus of Gentoo Linux and ensuring the confidentiality and security of our users machines is of utmost importance to us. Any security concerns should be addressed to [EMAIL PROTECTED] or alternatively, you may file a bug at http://bugs.gentoo.org. License === Copyright 2008 Gentoo Foundation, Inc; referenced text belongs to its owner(s). The contents of this document are licensed under the Creative Commons - Attribution / Share Alike license. http://creativecommons.org/licenses/by-sa/2.5 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH0uGhuhJ+ozIKI5gRAgVTAJwLRnRiWNfyNb/A7MCpSyt+SWckvQCeIkz2 Qb3ry7zddKcpZa4ecmV5Fas= =ealP -END PGP SIGNATURE- ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] [TKADV2008-001] Panda Internet Security/Antivirus+Firewall 2008 cpoint.sys Kernel Driver Memory Corruption Vulnerability
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Advisory: Panda Internet Security/Antivirus+Firewall 2008 cpoint.sys Kernel Driver Memory Corruption Vulnerability Advisory ID:TKADV2008-001 Revision: 1.0 Release Date: 2008/03/08 Last Modified: 2008/03/08 Date Reported: 2008/01/08 Author: Tobias Klein (tk at trapkit.de) Affected Software: Panda Internet Security 2008 Panda Antivirus+Firewall 2008 Remotely Exploitable: No Locally Exploitable:Yes Vendor URL: http://www.pandasecurity.com Vendor Status: Vendor has released a hotfix Patch development time: 60 days == Vulnerability details: == The kernel driver cpoint.sys shipped with Panda Internet Security and Antivirus+ Firewall 2008 contains a vulnerability in the code that handles IOCTL requests. Exploitation of this vulnerability can result in: 1) local denial of service attacks (system crash due to a kernel panic), or 2) local execution of arbitrary code at the kernel level (complete system compromise) The issue can be triggered by sending a specially crafted IOCTL request. No special user rights are necessary to exploit the vulnerability. == Technical description: == The IOCTL call 0xba002848 of the cpoint.sys kernel driver shipped with Panda Internet Security/Antivirus+Firewall 2008 accepts user supplied input that doesn't get validated enough. In consequence it is possible to cause an out-of-bound write in kernel memory. Disassembly of cpoint.sys (Windows Vista 32bit version): [...] .text:00012633 loc_12633: .text:00012633 mov edx, 0BA002848h <-- (1) .text:00012638 cmp ecx, edx .text:0001263A ja loc_12946 [...] .text:00012640 jz loc_128BE [...] .text:000128BE loc_128BE: .text:000128BE cmp [ebp+IOCTL_INPUT_SIZE], 1008h <-- (2) .text:000128C5 jb loc_12A7D [...] .text:000128CB mov esi, [ebp+IOCTL_INPUT_DATA] <-- (3) .text:000128CE cmp dword ptr [esi], 3F256B9Ah <-- (4) .text:000128D4 jnz loc_12A7D [...] .text:000128FF xor eax, eax .text:00012901 cmp [esi+8], eax <-- (5) .text:00012904 jbe short loc_1291B [...] (1) Vulnerable IOCTL call (2) IOCTL input size check (3) The user supplied data is copied into esi (4) + (5) Minor input data checks >From this point there are two different vulnerable code paths. Both will be described in the following: Vulnerable code path 1: [...] .text:00012906 lea ecx, [esi+0Ch] <-- (6) [...] .text:00012909 loc_12909: .text:00012909 mov edx, [ecx] <-- (7) .text:0001290B mov OVERWRITTEN_DATA[eax*4], edx <-- (8) .text:00012912 inc eax .text:00012913 add ecx, 4 .text:00012916 cmp eax, [esi+8] <-- (9) .text:00012919 jb short loc_12909 [...] (6) Some user controlled data is copied into ecx (7) The user controlled data is copied into edx (8) The user controlled data is copied (as dwords) at the memory location OVERWRITTEN_DATA (9) The size of the copied data (loop counter in eax) can be controlled by the user This leads to an out-of-bound write in kernel memory. Vulnerable code path 2: [...] .text:0001291B loc_1291B: .text:0001291B xor eax, eax .text:0001291D cmp [esi+10Ch], eax <-- (10) .text:00012923 jbe loc_129B4 [...] .text:00012929 lea ecx, [esi+110h] <-- (11) [...] .text:0001292F loc_1292F: .text:0001292F mov edx, [ecx] <-- (12) .text:00012931 mov OVERWRITTEN_DATA2[eax*4], edx <-- (13) .text:00012938 inc eax .text:00012939 add ecx, 4 .text:0001293C cmp eax, [esi+10Ch] <-- (14) .text:00012942 jb short loc_1292F [...] (10) Minor check of the user controlled data (11) Some user controlled data is copied into ecx (12) The user controlled data is copied into edx (13) The user controlled data is copied (as dwords) at the memory location OVERWRITTEN_DATA2 (14) The size of the copied data (loop counter in eax) can be controlled by the user This leads to an out-of-bound write in kernel memory. In both cases it is possible to write an arbitrary amount of user controlled data into kernel memory. As the data that gets overwritten is in the data section of the cpoint.sys kernel driver it is possible to control adjacent data structures (e.g. some KEVENT structures). If these structures are overwritten with carefully crafted data it is possible to force the windows kernel i
Re: [Full-disclosure] Firewire Attack on Windows Vista
>>What points are you trying to stab at for an article? You've hit on them pretty well. My own experience with DMA programming was 20 years ago with real mode DOS drivers, but I was surprised to learn from this thread that a DMA mass storage device on Linux, Mac and Windows gets unimpeded access to the full stretch of system memory. I take what I read here with a grain of salt, but the non-nut cases seem to be out and in agreement, at least about that. I'm not going to be writing a 20 page paper. I think I have 2 main questions I'll write about: How much should you worry about this and is it fixable (beyond disabling DMA, which is not a good solution if you ask me). You say it's fixable; that still leaves some questions for me whether the fix comes at the expense just of additional sophistication in the Firewire drivers or also a performance burden. I'll probably just leave it at a question. I actually do have a response fom Microsoft on the broader issue, but it doesn't address these issues or even concded that there's necessarily anything they can do about it. They instead speak of the same precautions for physical access that they spoke of a couple weeks ago with respect to the "frozen notebook memory" attack - use drive encryption, use 2-factor authentication, use hibernate instead of sleep, use group policy to enforce them. I don't think it's a bad response under the circumstances. The fact that you can turn off DMA on Linux seems in fact inferior to simply disabling the Firewire port and driver at run-time in Windows. They both suck as solutions. Incidentally, Microsoft made a few other points in their response that were interesting, but raised more questions than they answered: * it's possible for a user to disable 1394 DMA. I'm still looking into how you can do this. * it's possible for a user to "constrain a DMA device's memory access to specific ranges by using the physical DMA type." They say that some devices cannot be so restricted at all, and for others the restriction would only come at the cost of additional complexity and a performance hit, as I allude to above. I assume these considerations are generic to the hardware and not specific to Windows. How much should the average user worry about this? Not very much. Most notebooks from average users don't even have Firewire on them and you would have an easier time cracking them with a dictionary attack on the password and other such things, which means that this attack makes you no more vulnerable to compromise if you've already granted physical access than you were before. The frozen notebook memory attack seems a little too Mission Impossible for me to get worked up about. And if you're the sort of high-value target who needs to worrry about this sort of attack, there are measures you can take: use drive encryption, use 2-factor authentication, use hibernate instead of sleep, use group policy to enforce them. Larry Seltzer eWEEK.com Security Center Editor http://security.eweek.com/ http://blogs.pcmag.com/securitywatch/ Contributing Editor, PC Magazine [EMAIL PROTECTED] ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
