Re: [Full-disclosure] Hello gents
On Sun, 30 Apr 2006 09:18:16 -0700 MR BABS <[EMAIL PROTECTED]> wrote: >*Bantown is in no way affiliated with Dave Aitel or Immunity, Inc. Just like Gobbles isnt right? Oh wait... he works there now doesnt he. Concerned about your privacy? Instantly send FREE secure email, no account required http://www.hushmail.com/send?l=480 Get the best prices on SSL certificates from Hushmail https://www.hushssl.com?l=485 ___ 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] Secunia Research: WinHKI unacev2.dll Buffer Overflow Vulnerability
== Secunia Research 01/05/2006 - WinHKI unacev2.dll Buffer Overflow Vulnerability - == Table of Contents Affected Software1 Severity.2 Description of Vulnerability.3 Solution.4 Time Table...5 Credits..6 References...7 About Secunia8 Verification.9 == 1) Affected Software * WinHKI version 1.66 and 1.67. Prior versions may also be affected. == 2) Severity Rating: Moderately Critical Impact: System Access Where: Remote == 3) Description of Vulnerability Secunia Research has discovered a vulnerability in WinHKI, which can be exploited by malicious people to compromise a user's system. The vulnerability is caused due to a boundary error in ztvunacev2.dll (UNACEV2.DLL) when extracting an ACE archive containing a file with an overly long filename. This can be exploited to cause a stack-based buffer overflow when a user extracts a specially crafted ACE archive. The vulnerability is related to: SA16479 == 4) Solution Update to version 1.68. http://www.winhki.com/en/download.htm == 5) Time Table 30/03/2006 - Initial vendor notification. 01/04/2006 - Initial vendor reply. 01/05/2006 - Public disclosure. == 6) Credits Discovered by Tan Chew Keong, Secunia Research. == 7) References SA16479: http://secunia.com/advisories/16479/ == 8) About Secunia Secunia collects, validates, assesses, and writes advisories regarding all the latest software vulnerabilities disclosed to the public. These advisories are gathered in a publicly available database at the Secunia website: http://secunia.com/ Secunia offers services to our customers enabling them to receive all relevant vulnerability information to their specific system configuration. Secunia offers a FREE mailing list called Secunia Security Advisories: http://secunia.com/secunia_security_advisories/ == 9) Verification Please verify this advisory by visiting the Secunia website: http://secunia.com/secunia_research/2006-25/advisory/ Complete list of vulnerability reports published by Secunia Research: http://secunia.com/secunia_research/ == ___ 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 200605-01 ] MPlayer: Heap-based buffer overflow
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Gentoo Linux Security Advisory GLSA 200605-01 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - http://security.gentoo.org/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Severity: Normal Title: MPlayer: Heap-based buffer overflow Date: May 01, 2006 Bugs: #127969 ID: 200605-01 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Synopsis MPlayer contains multiple integer overflows that may lead to a heap-based buffer overflow. Background == MPlayer is a media player that supports many multimedia file types. Affected packages = --- Package /Vulnerable/ Unaffected --- 1 media-video/mplayer < 1.0.20060415>= 1.0.20060415 2 media-video/mplayer-bin < 1.0.20060415>= 1.0.20060415 --- 2 affected packages on all of their supported architectures. --- Description === Xfocus Team discovered multiple integer overflows that may lead to a heap-based buffer overflow. Impact == An attacker could entice a user to play a specially crafted multimedia file, potentially resulting in the execution of arbitrary code with the privileges of the user running the application. Workaround == There is no known workaround at this time. Resolution == All MPlayer users should upgrade to the latest version: # emerge --sync # emerge --ask --oneshot --verbose ">=media-video/mplayer-1.0.20060415" All MPlayer binary users should upgrade to the latest version: # emerge --sync # emerge --ask --oneshot --verbose ">=media-video/mplayer-bin-1.0.20060415" References == [ 1 ] CVE-2006-1502 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1502 Availability This GLSA and any updates to it are available for viewing at the Gentoo Security Website: http://security.gentoo.org/glsa/glsa-200605-01.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 2006 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.0 pgpflMVmILKBP.pgp Description: 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] DOS device name handling
Hi. * Overview: Valunerability exists in windows xp sp2 (others may also be affected), probably due to an error within the handling special device DOS names. In March 2000 Microsoft has patched similar problem in windows 98: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=4C6FD7E5-A66E-4A08-B782-2A64C77B95B6 * Environment: I tried this on polish windows xp sp2 with latest patches. Command outputs are translated into english, so they are not identical as in english version of xp. * Description: Using simple mkdir and rename commands it is possible to make directory structure which then can not be removed from disk without special, third party tools. Because even empty directory ocuppies some amount of disk space, this valunerability may be used against a user's machine by creating the millions of prepared, not eraseable directories. Other scenario may be renaming system or user's directory to invalid name. * Details: In a theory, windows does not allow programs to create directory containing special DOS device names (e.g. CON, LPT1, COM1, PRN). By simply adding a slash '/' character at the end of directory name, that protection fails. * Example: Assume we are on the root of drive C: Creating... mkdir "/foo/foo/foo/foo" Valid directory structure C:\foo\foo\foo\foo created. ... and renaming: cd \foo\foo\foo rename "foo" "con/" cd .. rename "foo" "con/" cd .. rename "foo" "con/" cd .. rename "foo" "con/" C:\ Now directory structure is: C:\con\con\con\con Please note that this is one way operation. Renaming from "con/" or "con" to "foo" does not work. However, if the directory has only one level (C:\con) and is empty or contains ,,normal'' entries, it is possible to remove it. Now, let's try browse: C:\cd "con" System nie może odnaleźć określonej ścieżki. [System can not find appropriate path.] C:\cd "con/" Nazwa katalogu jest nieprawidłowa. [Invalid directory name.] Let's try to rename: C:\rename "con" "foo" System nie może odnaleźć określonej ścieżki. [System can not find appropriate path.] C:\rename "con/" "foo" Nie można odnaleźć określonego pliku. [Could not find appropriate file.] And finally - removing: C:\>rmdir /S "con/" con/, Czy na pewno (T/N)? t [Are You sure (Y/N)?] con/\con\con\con\con - Nie można odnaleźć określonego pliku. con/\con\con\con - Nie można odnaleźć określonego pliku. con/\con\con - Nie można odnaleźć określonego pliku. con/\con - Nie można odnaleźć określonego pliku. [Could not find appropriate file.] Directory exists. C:\erase /S /Q "con" Nie można odnaleźć \\.\con. [Could not find \\.\con.] Please note a strange path. C:\erase /S /Q "con/" C:\ Directory *still* exists. Windows Explorer can browse directory, but renaming or removing fails. It looks like there is no simple way to remove C:\con from a disk. -- K. ___ 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] Yahoo Messenger Source Code Released: I.M Window Code
On 4/30/06, nocfed <[EMAIL PROTECTED]> wrote: oh noez! Oh yes! Yahoo! is going to scramble to obfuscate their javascript No their not, but their Yahoo > MSN partnership is going to be a hard one for them to secure this summer: http://messenger.yahoo.com/partners_msn.php url->view-source->new url->view-sourced! Then you are going to reverse engineer their javascript (ie: change a= into a friendly name like yahoosucks=) I'll leave that for pulltheplug.org #social Whatever shall we do? Die? Would you like to provide the javascript source to TOC or Microsoft Communicator next? No, i'll leave that to you guys at irc.pulltheplug.org #social so you, andrewg and nemo etc can take the credit and get off and give you something to type about on your worthless channel ;) This will defiantly cause a revolt against the big bad companies and get you hired. Indeed :) Really! It's good to have a guy at the water cooler that everyone can laugh at when real issues arise. Real issues, like pulltheplug.org #social have? Regards, n3td3v ___ 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] DOS device name handling
Dear Klaudiusz Kulik, This topic arises twice every year. Time to make answering machine. del \\?\c:\con\con\con\con del \\.\c:\con\con\con\con According to MSDN documentation \\?\ prefix makes Windows to ignore special device names and also eliminates 256 bytes path limitation. --Monday, May 1, 2006, 8:06:22 PM, you wrote to full-disclosure@lists.grok.org.uk: KK> Now directory structure is: KK> C:\con\con\con\con KK> Please note that this is one way operation. Renaming from "con/" or KK> "con" to "foo" does not work. However, if the directory has only one KK> level (C:\con) and is empty or contains ,,normal'' entries, it is KK> possible to remove it. -- ~/ZARAZA http://www.security.nnov.ru/ ___ 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] MSIE (mshtml.dll) OBJECT tag vulnerability
Tim Bilbo wrote: Setting aside analogies, the questions remain: Does full disclosure make the IT community as whole less secure than it would otherwise would be? Is it more dangerous to have a handfull of sophisticated blackhats lurking about with an unknown exploit vs. publishing it for every wannabe hacker to use? I am confident that the answer is that fully disclosing discovered vulnerabilites without first giving the vendor a reasonable chance to address them is more harmful. I'm confident in saying that full disclosure does not make the IT community as a whole less secure. My experience, both seeing the white hat and the black hat side of the community fence at different points in my life, is that the black hats will always have access to a certain substrata of information that those of us living in the world of light (i.e. not in a basement) will not have access to for some time. The problem with your question is that you're ultimately setting up an example that doesn't fit reality. The world you describe above is one where there are two tiers: Those with access to underground data and those without. The script kiddies on the outside, in the world described above, don't have access unless it's disclosed in public. The trouble is that the simplistic model doesn't represent reality. There are many strata in the black hat world and information is used until useless and then dumped into the lower strata as cannon fodder. What you do usually see with full disclosure (likewise with patching), which is ironically dragged out as an argument against full disclosure, is that when a flaw is disclosed, you do see script kiddies coming out of the woodwork making loud noises with automated bots mass-owning systems. Is this the fault of full disclosure? Nope. It's inevitable. There are no power structures in place to keep script kiddies from using what they find and making it their own. Of course, there's the world of law enforcement, which is effective at apprehending them after they do the deed, but as a deterrent you have to consider the type of person being dealt with: A person who feels marginalized by society and power structures in real life, often lashing out with power they have gained in the online world through the sheer lack of security on the Internet in general. The average script kiddie already has an inflated ego to counter the lack of self esteem they feel. Law enforcement as a deterrent to this type of person is not as effective as other people because the script kiddie already believes that he can't be caught. It's largely because of this multi-layer strata that we're talking about that makes your question somewhat moot. Are we more or less secure with or without full disclosure? Well, the question's pretty irrelevant now isn't it? Disclosure will always happen.. .the question is who will be doing the disclosure. Is it worse to have a skilled, quiet hacker who knows what he's doing on your network using 0-days, or an army of clumsy script kiddies writing worms that don't work half the time clogging up networks for one or two days a year -- not even really affecting most of the Internet or people who are security-wise in the first place? Personally, I think the more quiet, careful hacker is more dangerous. And in the end, it will always get out anyway... so you might as well bring it full circle sooner. Vendor disclosure before public disclosure is nice, but does not notifying the vendor inherently make us less secure? Well, I'd say not really. We were already insecure to begin with... and a state of secrecy doesn't make us more secure. It just means we don't know there's a problem that needs to be fixed. -bkfsec ___ 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] MSIE (mshtml.dll) OBJECT tag vulnerability
Bkfsec wrote: ... >"What you do usually see with full disclosure (likewise with patching), >which is ironically dragged out as an argument against full disclosure, >is that when a flaw is disclosed, you do see script kiddies coming out >of the woodwork making loud noises with automated bots mass-owning >systems. Is this the fault of full disclosure? Nope. It's >inevitable. " I don't think it is inevitable. Think about browser DoS vulnerabilties. An stealth blackhat wouldn't bother with that type of exploit. It's brute force, messy, doesn't get you root and it's trackable to some degree. But, lesser hackers will immediately adopt exploits that just crash the browser for example. So, by publishing that type of exploit and labeling it crtical you create a new requirement for mitigation that wouldn't otherwise be there. Some have suggested a 'Vulnerability Escrow' A third party that tracks and holds vulnerability discoveries and works with the vendor. I think that is an idea worth exploring. Tim iainsidethebeltway.typepad.org ___ 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] MSIE (mshtml.dll) OBJECT tag vulnerability
On Mon, 01 May 2006 14:51:23 EDT, Tim Bilbro said: > Some have suggested a 'Vulnerability Escrow' A third party that tracks > and holds vulnerability discoveries and works with the vendor. I think > that is an idea worth exploring. http://www.cert.org/reporting/vulnerability_form.txt BTDT. pgpe8QemlpLxI.pgp Description: 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] Re: DOS device name handling
Thanks ZARAZA for enlightenment. But... don't You think that it's stupid? If name is not allowed, why it is when '/' is appended? In fact these names are the same, effects of using these names are the same [with or without '/']. And if name is not allowed, why I may create that prohibited directory? Really, I don't understand. According to MSDN - - it's feature, but I have doubt. Anyway - thanks again for reply. -- K. ___ 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] Re: DOS device name handling
On Mon, 01 May 2006 21:58:22 +0200, Klaudiusz Kulik said: > > Thanks ZARAZA for enlightenment. But... don't You think that it's > stupid? If name is not allowed, why it is when '/' is appended? > In fact these names are the same, effects of using these names are the > same [with or without '/']. And if name is not allowed, why I may create > that prohibited directory? Really, I don't understand. According to MSDN - > - it's feature, but I have doubt. Anyway - thanks again for reply. http://www.catb.org/~esr/jargon/html/B/BAD.html pgpdUSz3bXGKJ.pgp Description: 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/
Re: [Full-disclosure] MSIE (mshtml.dll) OBJECT tag vulnerability
Tim Bilbro wrote: I don't think it is inevitable. Think about browser DoS vulnerabilties. An stealth blackhat wouldn't bother with that type of exploit. It's brute force, messy, doesn't get you root and it's trackable to some degree. But, lesser hackers will immediately adopt exploits that just crash the browser for example. So, by publishing that type of exploit and labeling it crtical you create a new requirement for mitigation that wouldn't otherwise be there. If a script kiddie wants to DoS a browser, there are very easy ways to do so without resorting to arcane tricks. Resource consumption/misuse has always been an easy game to master. I think that your example here is a very very poor one. It's like saying that the fork bomb is a well guarded secret. It's inevitable. If it's a known hole anywhere, it's a matter of time until it gets out. The issues that count, the ones that both black hats and script kiddies care about that get them access, they will always follow the pattern I laid out because it's beneficial to the skilled black hats to do it that way. Some have suggested a 'Vulnerability Escrow' A third party that tracks and holds vulnerability discoveries and works with the vendor. I think that is an idea worth exploring. I think it's a horrible idea that only creates people with a vested interest in getting paid to hold vulnerabilities in secret. There's no way to enforce its usage and as such it will never result in a lack of disclosure. The "escrow" services will become targets of attacks and eventually, because greed always wins, this new flashy database of 0-days will be sold off to the highest bidder. I think it's a monumentally bad idea to collect all vulnerability data necessary for the company to fix their product in one place and leave it in the hands of people who only have a monetary goal in their holding of that data. -bkfsec ___ 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] MSIE (mshtml.dll) OBJECT tag vulnerability
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Tim Bilbro wrote: > Bkfsec wrote: > > ... > >> "What you do usually see with full disclosure (likewise with patching), > >> which is ironically dragged out as an argument against full disclosure, > >> is that when a flaw is disclosed, you do see script kiddies coming out >> of the woodwork making loud noises with automated bots mass-owning >> systems. Is this the fault of full disclosure? Nope. It's >> inevitable. " > > > I don't think it is inevitable. No offense intended here, but to argue that point is deluded. If there's sufficient value to discovering it, it will be discovered. > Think about browser DoS vulnerabilties. > An stealth blackhat wouldn't bother with that type of exploit. It's > brute force, messy, doesn't get you root and it's trackable to some > degree. But, lesser hackers will immediately adopt exploits that just > crash the browser for example. So, by publishing that type of exploit > and labeling it crtical you create a new requirement for mitigation that > wouldn't otherwise be there. This is a TERRIBLE example. Some vendors (Microsoft) don't patch browser DoS bugs unless they've later proven exploitable. Most of the community doesn't even consider them vulnerabilities. Further, the mitigation is so simple that it doesn't even require policy to implement: if your browser crashes, don't go back to that site. Put simply: if you discover that doing something hurts, don't do it again. There's no continuing damage. It's a fundamental law of browser security that nobody can force you to go to a malicious site, and crashing a browser is not a sufficient inconvenience that policy mitigation or security assets are required. Because such methods are trivial to discover (and some are simply matters of heavy-client design) and difficult to effectively fix, there's substantial motive and ability within the group we'd normally consider "script kiddies" to find such bugs. > Some have suggested a 'Vulnerability Escrow' A third party that tracks > and holds vulnerability discoveries and works with the vendor. I think > that is an idea worth exploring. It's an idea that's been explored and failed miserably. As Valdis already hinted at, CERT/CC is a disaster. Public disclosure of vulnerabilities provides the only means of accountability. Would you support a "vulnerability escrow" that sat on reports of security holes for an eternity if a vendor decided patching them was too much of an inconvenience? I sincerely hope not, because I know that I would have no part in such "disclosures". Further, as a member of the public, I'd object strongly to their existence. Surprise: CERT/CC did exactly that when it began. Unfortunately, when you deny the public information, they have no calling to hold the vendor accountable. Incomplete information also hinders the ability of the public to even make a reasonable guess as to the security of the product and the commitment of its developer to that security. Oracle, for instance, is laughed at because they take 800 or so days to fix serious security holes and only occasionally get it right. In your world of "escrow", nobody knows that, because there's no public information. So, people aren't informed and as a result, can't stay away from vendors whose security processes are colossal failures. But it gets worse. What about in an "escrowed" world when vendors do release patches? How do admins prioritize? Or do they just blindly apply every patch and hope nothing breaks? Because you can bet that people will be out there taking apart those patches and finding what they fix. Anybody who doesn't apply them in that short (and shrinking) timeframe is begging to get owned, and wouldn't even have a clue. Further, how do you propose to make people USE such an escrow system, especially if it denies them the choice of public disclosure? How do you ACTUALLY propose to deny people that choice? Ooooh, ooh, I have some ideas! 1) Let's all rally around some toothless standard that says "We, the vendors agree to patch within two centuries" with all accountability stripped away by non-disclosure. The vendors are trustworthy, and they'll all patch, because your security (and not their bottom line) is the priority. 2) Let's have the U.S. pass another speech-squelching law ala DMCA, export it to every country with a computer via fifteen thousand FTAs promising the "enormous benefits" of "free access" to a U.S. economy where everything from abortion to broad-tipped markers is puritanically-regulated and make it so that reverse-engineering patches is... illegal!!! That would solve it! Seriously now... you've gotta be kidding me. But let's take it another step. Since we can't actually STOP people from reversing patches, let's just NOT PATCH! Trust our luck. Let's all just be birds flying through the sky waiting for the first moderately-clued malicious person with the tools to shoot technic
[Full-disclosure] [ MDKSA-2006:080 ] - Updated clamav packages fix vulnerability
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ___ Mandriva Linux Security Advisory MDKSA-2006:080 http://www.mandriva.com/security/ ___ Package : clamav Date: May 1, 2006 Affected: 10.2, 2006.0, Corporate 3.0 ___ Problem Description: Ulf Harnhammar discovered that the freshclam tool does not do a proper check for the size of header data received from a web server. This could potentially allow a specially prepared HTTP server to exploit freshclam clients connecting to a database mirror and causing a DoS. The updated packages have been updated to Clamav 0.88.2 which corrects this problem. ___ References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1989 ___ Updated Packages: Mandriva Linux 10.2: 504700848a3d4d5c6cd56bc599f72a01 10.2/RPMS/clamav-0.88.2-0.1.102mdk.i586.rpm 565dc413c1827141490cf9d3f8638dc4 10.2/RPMS/clamav-db-0.88.2-0.1.102mdk.i586.rpm 0d15660c887ed3b728068c4be742c2c4 10.2/RPMS/clamav-milter-0.88.2-0.1.102mdk.i586.rpm cb0f6327f6b544bb5785f976837c6534 10.2/RPMS/clamd-0.88.2-0.1.102mdk.i586.rpm b1290d2aef3fb5fddd2960cf724ddb4a 10.2/RPMS/libclamav1-0.88.2-0.1.102mdk.i586.rpm 78b7ffa7cd5ffd9b97d9e2cbd764dd67 10.2/RPMS/libclamav1-devel-0.88.2-0.1.102mdk.i586.rpm 9c25ddd53c49a94613cba04d487f1d67 10.2/SRPMS/clamav-0.88.2-0.1.102mdk.src.rpm Mandriva Linux 10.2/X86_64: 21995c6aba38f1dce3ab59e595366869 x86_64/10.2/RPMS/clamav-0.88.2-0.1.102mdk.x86_64.rpm 070fc66c387ac0c48182c94223e68aef x86_64/10.2/RPMS/clamav-db-0.88.2-0.1.102mdk.x86_64.rpm 1ee9e18a46da275aae4d218749aefa2c x86_64/10.2/RPMS/clamav-milter-0.88.2-0.1.102mdk.x86_64.rpm d7e05378a54d9340e031b1be7ebc1d9c x86_64/10.2/RPMS/clamd-0.88.2-0.1.102mdk.x86_64.rpm 57d2cc1e2604f9a67707c9e32d5912bb x86_64/10.2/RPMS/lib64clamav1-0.88.2-0.1.102mdk.x86_64.rpm 080bc0894bb82a9ccb3c583099b7ff21 x86_64/10.2/RPMS/lib64clamav1-devel-0.88.2-0.1.102mdk.x86_64.rpm 9c25ddd53c49a94613cba04d487f1d67 x86_64/10.2/SRPMS/clamav-0.88.2-0.1.102mdk.src.rpm Mandriva Linux 2006.0: 04b9eaa22e3709a556355d1a63f325d3 2006.0/RPMS/clamav-0.88.2-0.1.20060mdk.i586.rpm b42db252b6017e518cd97bc3852d6501 2006.0/RPMS/clamav-db-0.88.2-0.1.20060mdk.i586.rpm 3b0002e7113f98b2d464db0d83e82937 2006.0/RPMS/clamav-milter-0.88.2-0.1.20060mdk.i586.rpm 824f1c08ea56fca696204d2c17474763 2006.0/RPMS/clamd-0.88.2-0.1.20060mdk.i586.rpm 59cf5dabda1ec2d4c00607c61568603c 2006.0/RPMS/libclamav1-0.88.2-0.1.20060mdk.i586.rpm 5fa8e2280cd07c19f14c13d8ef6a808d 2006.0/RPMS/libclamav1-devel-0.88.2-0.1.20060mdk.i586.rpm 8f8d2d75378f599ec0ad4bb0c4b4c718 2006.0/SRPMS/clamav-0.88.2-0.1.20060mdk.src.rpm Mandriva Linux 2006.0/X86_64: 31d57fe2b7213ef6a553efbb54e9fd44 x86_64/2006.0/RPMS/clamav-0.88.2-0.1.20060mdk.x86_64.rpm cd92749b954d7e683e63ac91465279cf x86_64/2006.0/RPMS/clamav-db-0.88.2-0.1.20060mdk.x86_64.rpm cd67db062928aab0bff452d548c8f109 x86_64/2006.0/RPMS/clamav-milter-0.88.2-0.1.20060mdk.x86_64.rpm 32220d09761f344b256c402b362fdf44 x86_64/2006.0/RPMS/clamd-0.88.2-0.1.20060mdk.x86_64.rpm 80e899d781d667614ff1be548473469c x86_64/2006.0/RPMS/lib64clamav1-0.88.2-0.1.20060mdk.x86_64.rpm 0a926463dde3f8f730b3088b454033be x86_64/2006.0/RPMS/lib64clamav1-devel-0.88.2-0.1.20060mdk.x86_64.rpm 8f8d2d75378f599ec0ad4bb0c4b4c718 x86_64/2006.0/SRPMS/clamav-0.88.2-0.1.20060mdk.src.rpm Corporate 3.0: 9e293869d32057fd0eb32489c2668c9a corporate/3.0/RPMS/clamav-0.88.2-0.1.C30mdk.i586.rpm e727b5102b3b7ecd1580c7671825ed24 corporate/3.0/RPMS/clamav-db-0.88.2-0.1.C30mdk.i586.rpm 016b4eac4f1dda299d3ef4a708ba11c2 corporate/3.0/RPMS/clamav-milter-0.88.2-0.1.C30mdk.i586.rpm 7c715a9f07a204fdf070eac3c7dd264a corporate/3.0/RPMS/clamd-0.88.2-0.1.C30mdk.i586.rpm 47b553230f4070d12995a4ae9c1a4111 corporate/3.0/RPMS/libclamav1-0.88.2-0.1.C30mdk.i586.rpm 8d11c95524b35b91b29da262cee7ce3e corporate/3.0/RPMS/libclamav1-devel-0.88.2-0.1.C30mdk.i586.rpm b702a7862c123c89bdea7d0ab72aea38 corporate/3.0/SRPMS/clamav-0.88.2-0.1.C30mdk.src.rpm Corporate 3.0/X86_64: 4309266e4bacf97d9025d688cfe88cd8 x86_64/corporate/3.0/RPMS/clamav-0.88.2-0.1.C30mdk.x86_64.rpm 2f14c88331222593e2a24bc8a28c1dfc x86_64/corporate/3.0/RPMS/clamav-db-0.88.2-0.1.C30mdk.x86_64.rpm 9b810d09669a131f80354dee61e8ab6e x86_64/corporate/3.0/RPMS/clamav-milter-0.88.2-0.1.C30mdk.x86_64.rpm f5cf957964da35212b5216ef61db6cb6 x86_64/corporate/3.0/RPMS/clamd-0.88.2-0.1.C30mdk.x86_64.rpm fdaffd2efa64f9a4613398ae7c299509 x86_64/corporate/3.0/RPMS/lib64clamav1-0.88.2-0.1.C30mdk.x86_64.rpm 4f33c005fd172e9c6de84368cf51c681 x86_64/corporate/3.0/RPMS/lib64clamav1-devel-0.
[Full-disclosure] Cisco Security Advisory: Cisco Unity Express Expired Password Reset Privilege Escalation
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Cisco Security Advisory: Cisco Unity Express Expired Password Reset
Privilege Escalation
Advisory ID: cisco-sa-20060501-cue
http://www.cisco.com/warp/public/707/cisco-sa-20060501-cue.shtml
Revision 1.0
For Public Release 2006 May 01 2300 UTC (GMT)
+
Contents
Summary
Affected Products
Details
Impact
Software Version and Fixes
Workarounds
Obtaining Fixed Software
Exploitation and Public Announcements
Status of this Notice: FINAL
Distribution
Revision History
Cisco Security Procedures
+
Summary
===
Cisco Unity Express (CUE) contains a vulnerability that might allow
an authenticated user to change the password for another user by
using the HTTP management interface, if the password for the user
being modified is marked as expired. This can result in a privilege
escalation attack and complete administrative control of a CUE
module, if the password being changed belongs to an administrator.
There are mitigations for this vulnerability.
Cisco has made free software available to address this vulnerability
for affected customers.
This advisory is posted at
http://www.cisco.com/warp/public/707/cisco-sa-20060501-cue.shtml
Affected Products
=
Vulnerable Products
+--
Any CUE Advanced Integration Module (AIM) or Network Module (NM)
running CUE software versions prior to 2.3(1) is affected by this
vulnerability.
The version of software running on a CUE module can be determined
using the show software versions command in the CUE command line
interface or by selecting Help > About in the HTTP management
interface.
cue-10-0-0-1# show software versions
Installed Packages:
- Bootloader (Primary) 2.1.2
- Global 2.2.0
- GPL Infrastructure 2.1.2
- Voice Mail 2.1.2
- Bootloader (Secondary) 2.1.2
- Installer 2.1.1
- Core 2.1.2
- Auto Attendant 2.1.2
Installed Languages:
- US English 2.1.0
Installed Languages:
- US English 1.1.1
The CUE version is determined by the Core package.
Products Confirmed Not Vulnerable
+
No other Cisco products, including Cisco Unity, are currently known
to be affected this vulnerability.
Details
===
Cisco Unity Express (CUE) is an optional hardware module designed for
use with Cisco modular routers to provide voice mail and automated
attendant services. The HTTP management interface of a CUE module
allows authenticated users to change their password. This
vulnerability allows authenticated users to change the password for
any user with an expired password. If an administrator's account has
expired, the administrator's password can be changed allowing an
unprivileged user to gain complete administrative control of a CUE
module.
There are three ways for a user to have an expired password.
* Newly created users with blank passwords. CUE treats blank
passwords as expired. This feature was introduced in CUE software
version 1.1(1).
* Newly created users with a randomly selected password.
Administrators can elect to have a random password assigned when
creating new users. CUE treats the random passwords as expired.
This feature was introduced in CUE software version 1.1(1).
* If the system-wide password expiry feature is enabled, user
passwords can be configured to expire after a specified number of
days. Users with expired passwords are required to change their
password. This feature was introduced in CUE software version 2.1
(1).
The vulnerability is documented in the following Cisco Bug ID:
* CSCsd50387 ( registered customers only) Cisco Unity Express
Expired Password Reset Privilege Escalation
Impact
==
Successful exploitation of the vulnerability may allow an
unprivileged user to gain complete administrative control of a CUE
module. This may result in the disclosure of sensitive information
contained in voice mail stored on a CUE module and possible negative
publicity if automated attendant messages are maliciously changed.
Software Version and Fixes
==
When considering software upgrades, also consult
http://www.cisco.com/go/psirt and any subsequent advisories to
determine exposure and a complete upgrade solution.
In all cases, customers should exercise caution to be certain the
devices to be upgraded contain sufficient memory and that current
hardware and software configurations will continue to be supported
properly by the new release. If the information is not clear, contact
the Cisco Technical Assistance Center ("TAC") or your contracted
maintenance provider for assistance.
Fixed software can be downloaded at
http://www.cisco.com/cgi-bin/tablebuild.
