Re: [Full-disclosure] defeating voice captchas
Gadi Evron wrote: Therefore, how many times does one have to refresh the page and listen to the Captcha to be able to simply learn to identify the Captcha by say, an MD5 hash of the audio for each letter? That is just a bad implementation, when done well audio Captchas are probably as secure as their visual counterparts. Done well means that, besides the 10 digits (and/or 26 letters) recorded by the sexy voice and replayed in a random order, the audio is mixed with multiple sound sources, different for each generated Captcha. For example, you can use a symphony(*), random white noise, the sound of the street, or all of these, at a level of 3 or 6 dB above the voice. The brain can easily distinguish the secret code from all the background noise, but it's much more difficult for a computer. While I'm not an audio expert either, I'm sure this problem is allot harder than a simple MD5 - just look how bad state of the art voice recognition software performs in almost ideal conditions, i.e. no background noise etc. (*) Of course, it's better to use sound sources that are hard to identify, and are ideally not available to the attacker; else he could obtain the same sounds and subtract them from the audio. I think some random pitch shifting (tremolo) would help against this. ___ 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] [SECURITY] [DSA 971-1] New xpdf packages fix denial of service
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Debian Security Advisory DSA 971-1 [EMAIL PROTECTED] http://www.debian.org/security/ Martin Schulze February 14th, 2006 http://www.debian.org/security/faq - -- Package: xpdf Vulnerability : buffer overflow Problem type : local (remote) Debian-specific: no CVE ID : CVE-2006-0301 Debian Bugs: 350783 350785 SuSE researchers discovered heap overflow errors in xpdf, the Portable Document Format (PDF) suite, that can allow attackers to cause a denial of service by crashing the application or possibly execute arbitrary code. The old stable distribution (woody) is not affected. For the stable distribution (sarge) these problems have been fixed in version 3.00-13.5. For the unstable distribution (sid) these problems have been fixed in version 3.01-6. We recommend that you upgrade your xpdf packages. Upgrade Instructions - wget url will fetch the file for you dpkg -i file.deb will install the referenced file. If you are using the apt-get package manager, use the line for sources.list as given below: apt-get update will update the internal database apt-get upgrade will install corrected packages You may use an automated update by adding the resources from the footer to the proper configuration. Debian GNU/Linux 3.1 alias sarge - Source archives: http://security.debian.org/pool/updates/main/x/xpdf/xpdf_3.00-13.5.dsc Size/MD5 checksum: 781 7ce45eb5717a12dc1d0bf61e24481486 http://security.debian.org/pool/updates/main/x/xpdf/xpdf_3.00-13.5.diff.gz Size/MD5 checksum:50970 a6099c15a50cca42122437ab563d940e http://security.debian.org/pool/updates/main/x/xpdf/xpdf_3.00.orig.tar.gz Size/MD5 checksum: 534697 95294cef3031dd68e65f331e8750b2c2 Architecture independent components: http://security.debian.org/pool/updates/main/x/xpdf/xpdf-common_3.00-13.5_all.deb Size/MD5 checksum:56526 0e1ca9d78ff1514d3ae44b97c687f86d http://security.debian.org/pool/updates/main/x/xpdf/xpdf_3.00-13.5_all.deb Size/MD5 checksum: 1282 2ac965346896b6386f1d4ec4ccea3a23 Alpha architecture: http://security.debian.org/pool/updates/main/x/xpdf/xpdf-reader_3.00-13.5_alpha.deb Size/MD5 checksum: 802316 afd3ae2a4b2c29e53711d3e94c8bc3ea http://security.debian.org/pool/updates/main/x/xpdf/xpdf-utils_3.00-13.5_alpha.deb Size/MD5 checksum: 1528196 9326b36c0de9f88ed71d1b4326864016 AMD64 architecture: http://security.debian.org/pool/updates/main/x/xpdf/xpdf-reader_3.00-13.5_amd64.deb Size/MD5 checksum: 668024 0ac3c9fdf7db18a21cb3f4860fc45060 http://security.debian.org/pool/updates/main/x/xpdf/xpdf-utils_3.00-13.5_amd64.deb Size/MD5 checksum: 1273740 6651a2d57abd1bc1bd95afb84b34ef97 ARM architecture: http://security.debian.org/pool/updates/main/x/xpdf/xpdf-reader_3.00-13.5_arm.deb Size/MD5 checksum: 674596 a02c5ba26c13f413df130b41834e4a26 http://security.debian.org/pool/updates/main/x/xpdf/xpdf-utils_3.00-13.5_arm.deb Size/MD5 checksum: 1279042 00f092c20580c2e843d3e03bb596f740 Intel IA-32 architecture: http://security.debian.org/pool/updates/main/x/xpdf/xpdf-reader_3.00-13.5_i386.deb Size/MD5 checksum: 656924 20e1a2d5df073d7a6901d64372645281 http://security.debian.org/pool/updates/main/x/xpdf/xpdf-utils_3.00-13.5_i386.deb Size/MD5 checksum: 1242172 493b3c13e595a0892ba389df34298aa9 Intel IA-64 architecture: http://security.debian.org/pool/updates/main/x/xpdf/xpdf-reader_3.00-13.5_ia64.deb Size/MD5 checksum: 951018 1ee0583a594703d9eb83af9e690d0d18 http://security.debian.org/pool/updates/main/x/xpdf/xpdf-utils_3.00-13.5_ia64.deb Size/MD5 checksum: 1801954 e7a3b8b5bf581cc3992152788ca99c4b HP Precision architecture: http://security.debian.org/pool/updates/main/x/xpdf/xpdf-reader_3.00-13.5_hppa.deb Size/MD5 checksum: 832812 d75a012fc64a7fdc36908b79773183cd http://security.debian.org/pool/updates/main/x/xpdf/xpdf-utils_3.00-13.5_hppa.deb Size/MD5 checksum: 1580484 6dca8d1089e594508c94de51e258ad4f Motorola 680x0 architecture: http://security.debian.org/pool/updates/main/x/xpdf/xpdf-reader_3.00-13.5_m68k.deb Size/MD5 checksum: 585998 36903201584950e883b7eec288337cbf http://security.debian.org/pool/updates/main/x/xpdf/xpdf-utils_3.00-13.5_m68k.deb Size/MD5 checksum: 1116744 17d5c5c950157fc7da3918769b7a8852 Big endian MIPS architecture: http://security.debian.org/pool/updates/main/x/xpdf/xpdf-reader_3.00-13.5_mips.deb Size/MD5 checksum: 807914 3bbadfbfa77e463487f75538ce89cb39
Re: [Full-disclosure] defeating voice captchas
did someone tried to perform a sound bruteforce attack against something like a voice-password protected PDA? /JA ___ 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] working of winpcap
On Mon, 2006-02-13 at 03:27 -0800, yogesh choubey wrote: Hi Aditya, i am yogesh , want to know more about winpcap. how it works?still after reading from site winpcap ,i am not able to get depper in it.please helpme by providing some document. Thanks Regards Yogesh Kumar The documentation on the website covers basically how WinPcap works. They also provide developer documentation and source code which gives you an in depth look at how the program works. http://www.winpcap.org/devel.htm -- With Regards.. Barrie Dempster (zeedo) - Fortiter et Strenue He who hingeth aboot, geteth hee-haw Victor - Still Game blog: http://reboot-robot.net sites: http://www.bsrf.org.uk - http://www.security-forums.com ca:https://www.cacert.org/index.php?id=3 smime.p7s Description: S/MIME cryptographic 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] defeating voice captchas
Stelian Ene wrote: Gadi Evron wrote: Therefore, how many times does one have to refresh the page and listen to the Captcha to be able to simply learn to identify the Captcha by say, an MD5 hash of the audio for each letter? That is just a bad implementation, when done well audio Captchas are probably as secure as their visual counterparts. Done well means that, besides the 10 digits (and/or 26 letters) recorded by the sexy voice and replayed in a random order, the audio is mixed with multiple sound sources, different for each generated Captcha. For example, you can use a symphony(*), random white noise, the sound of the street, or all of these, at a level of 3 or 6 dB above the voice. The brain can easily distinguish the secret code from all the background noise, but it's much more difficult for a computer. While I'm not an audio expert either, I'm sure this problem is allot harder than a simple MD5 - just look how bad state of the art voice recognition software performs in almost ideal conditions, i.e. no background noise etc. (*) Of course, it's better to use sound sources that are hard to identify, and are ideally not available to the attacker; else he could obtain the same sounds and subtract them from the audio. I think some random pitch shifting (tremolo) would help against this. OK. Use voice recognition. ___ 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: On the 0-day term
Steven M. Christey wrote: Hey Steve! :) It's not necessarily that 0-days are a myth, it's that people have been using the term 0-day to mean two separate things: 0days are not a myth on their own. They are live and kickin`! :) - in-the-wild hacks of live systems using vulnerabilities previously unkown to the public and the vendor; - release of exploit information for vulnerabilities previously unkown to the public and the vendor, for which there are no known in-the-wild hacks of live systems at the time of disclosure (though such hacks seem to occur very soon afterward) I don't know, last year I read an article about 0days being released vulnerabilities where the patch is not applied yet. Uh huh. Does anyone still think bad guys don't exploit (to whatever goals) a 0day if it is out there? The answer seems obvious, but... It's not entirely clear to me how many in-the-wild 0-days exist and are actively exploited. Just because some white hat finds something does not mean that we should ALWAYS assume that the black hats already know about it. The converse is also true, of course; see the On this point I disagree. We have to assume the worst, especially where we are specifically vulnerable. And as today we mostly rely on software security on-top of software security for our defense - we HAVE to assume the worst... we just don't have to hype it, and possibly, we can call it what it really is. recent WMF issue. The goal of said 0day may be for specific attacks against specific targets. I don't see why anyone would waste their secret strong resource on the wild west of the net - we don't often find 0days, right? Microsoft's or SecurityFocus's sites don't go down that often, right? WMF was an exploit of opportunity, i.e.: what is our window of opportunity to infect users with spyware before we are found out? In this case it was about 2 weeks. This came to show that spyware manufacturers either did their own RD or bought 0days. This is not the first time, either. Certainly, at least a couple in-the-wild 0-days are publicized a year, and maybe more in the coming year, given the precedents of the past 6 months or so, as the honeymonkeys project and Websense have shown. One would hope that there is some critical mass (i.e. number of compromised systems) beyond which any in-the-wild 0-day would become publicly known. This cricital mass would depend on the diligence of the incident response community and the amount of coordination - direct or indirect - with the vulnerability research community. Critical mass could also be one well-placed machine. Point is we need to differentiate between, but not limited to: 1. Vulns that were already disclosed to the vendor or CC's. 2. Vulns that are publicly announce OR released by advisory or similar. and 3. Vulns that no one knows exist, whether being exploited wildly, kept in a bunker or used on special targets. It's time we stopped guessing and starting regulating these terms, not because we can tell people how to use the term '0day' but rather what it might mean. Makes lives so much easier. In some of the above cases I will be proud to yell: THERE ARE NO 0DAYS, while I know that's obviously false in other cases. The problem with this email, as well as any other to follow is that they are all full of opinions. We have to stop being an opinion-lead industry where opinions constitute 90% (didn't make any specific calculation, that's my opinion) of how we do things professionally. - Steve I really hope this is not to become another long debate on religious terminology.. what have I done?! Gadi. ___ 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: defeating voice captchas
(*) Of course, it's better to use sound sources that are hard to identify, and are ideally not available to the attacker; else he could obtain the same sounds and subtract them from the audio. I think some random pitch shifting (tremolo) would help against this. OK. Use voice recognition. We all know how well those work! Using IVR systems which reliably detect what I say when I speak slowly and clearly without sounding like Basil Faulty speaking to Manuel are non existent. So surely the reverse would be true of any voice recognition system applied to voice captchas. ___ 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: On the 0-day term
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 0day just mean the day released, its mostly a term used in the warez scene to qualify new app/mp3 cracked each days, as exploits released each days ... Gadi Evron wrote: Steven M. Christey wrote: Hey Steve! :) It's not necessarily that 0-days are a myth, it's that people have been using the term 0-day to mean two separate things: 0days are not a myth on their own. They are live and kickin`! :) - in-the-wild hacks of live systems using vulnerabilities previously unkown to the public and the vendor; - release of exploit information for vulnerabilities previously unkown to the public and the vendor, for which there are no known in-the-wild hacks of live systems at the time of disclosure (though such hacks seem to occur very soon afterward) I don't know, last year I read an article about 0days being released vulnerabilities where the patch is not applied yet. Uh huh. Does anyone still think bad guys don't exploit (to whatever goals) a 0day if it is out there? The answer seems obvious, but... It's not entirely clear to me how many in-the-wild 0-days exist and are actively exploited. Just because some white hat finds something does not mean that we should ALWAYS assume that the black hats already know about it. The converse is also true, of course; see the On this point I disagree. We have to assume the worst, especially where we are specifically vulnerable. And as today we mostly rely on software security on-top of software security for our defense - we HAVE to assume the worst... we just don't have to hype it, and possibly, we can call it what it really is. recent WMF issue. The goal of said 0day may be for specific attacks against specific targets. I don't see why anyone would waste their secret strong resource on the wild west of the net - we don't often find 0days, right? Microsoft's or SecurityFocus's sites don't go down that often, right? WMF was an exploit of opportunity, i.e.: what is our window of opportunity to infect users with spyware before we are found out? In this case it was about 2 weeks. This came to show that spyware manufacturers either did their own RD or bought 0days. This is not the first time, either. Certainly, at least a couple in-the-wild 0-days are publicized a year, and maybe more in the coming year, given the precedents of the past 6 months or so, as the honeymonkeys project and Websense have shown. One would hope that there is some critical mass (i.e. number of compromised systems) beyond which any in-the-wild 0-day would become publicly known. This cricital mass would depend on the diligence of the incident response community and the amount of coordination - direct or indirect - with the vulnerability research community. Critical mass could also be one well-placed machine. Point is we need to differentiate between, but not limited to: 1. Vulns that were already disclosed to the vendor or CC's. 2. Vulns that are publicly announce OR released by advisory or similar. and 3. Vulns that no one knows exist, whether being exploited wildly, kept in a bunker or used on special targets. It's time we stopped guessing and starting regulating these terms, not because we can tell people how to use the term '0day' but rather what it might mean. Makes lives so much easier. In some of the above cases I will be proud to yell: THERE ARE NO 0DAYS, while I know that's obviously false in other cases. The problem with this email, as well as any other to follow is that they are all full of opinions. We have to stop being an opinion-lead industry where opinions constitute 90% (didn't make any specific calculation, that's my opinion) of how we do things professionally. - Steve I really hope this is not to become another long debate on religious terminology.. what have I done?! Gadi. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) iQIVAwUBQ/HU4K+LRXunxpxfAQJmSQ//fmj9Me1Zq3e+gczohbl6GnDDA7weLeQU yzoZFTdKK8JuL+rjlgbLkzDXlah8UaS6CYImYANHg8YfJW2a27pMzIizGqC58ILe LZSAcQw3K23cu/BuB7yX5kJoj0jcZzjz0mLqHzMGU9JcwiFl/UsLK6Jc7pRsa1/T vspJYMkTj0b8pwCdkF8EGqr5pDL0qGeSTgONna2eZhmDq0kSXnDTtGOXjDsvvcvz 5QVrX/uXhAZWJSZKe690K+/tJzVLJtTtAm3yQfw0a+P5HsT3cTGSJQ0Dns4Yy357 Bzrzegz5V9MTYdUtlZresfQ+DXqTE0XbBskFeN0GmBB6pr1R0IPdnojXJyK2ZY+u ukypO+n5kabSIAskdUamTQyszsDKuGmKdqV2osyt4nk50ob9eK4a6gSvOv0bcWc9 wTv51aCwEAX8MOR70SPu43b2YsFqsMkF8fxNmjY+X7xBt2FtuA9od4t2ApPiticU wutSEvLk2UNmJNiR/YJESqHic8OVR+KEf65NEIJ/lZDgLXrocW2bFG99+T97j2zF G+VnIG9qU28G0w3+tzOEoD3/krB/6l4tm5Zae6SMN543BhLgA3oGC7zeybYjeAOX 5OS3K0i1pUJIhUyp/bUx6a/2t1r02CUqCpcL26dOvTzkysXEUOlyF2Wj+7kXo2QD trkEmkW5tk4= =BS4A -END PGP SIGNATURE- ___
[Full-disclosure] Anybody else getting trojans from someone masquerading as fyodor?
I've received two messages in the past few hours from 59.144.22.69, pretending to be from [EMAIL PROTECTED] Both contain a binhex'd UPX packed SCR attachment. Is it just me? Headers below: Return-Path: [EMAIL PROTECTED] X-Original-To: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] Received: from dallas (unknown [59.144.22.69]) by beigebox.liquidev.com (Postfix) with SMTP id 8F3CF174035 for [EMAIL PROTECTED]; Tue, 14 Feb 2006 13:37:32 + (GMT) From: fyodor [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Fwd: image.jpg MIME-Version: 1.0 Content-Type: multipart/mixed; boundary==_NextPart_2.38107085227966E-02 Message-Id: [EMAIL PROTECTED] Date: Tue, 14 Feb 2006 13:37:32 + (GMT) Return-Path: [EMAIL PROTECTED] X-Original-To: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] Received: from dallas (unknown [59.144.22.69]) by beigebox.liquidev.com (Postfix) with SMTP id 9CC80174035 for [EMAIL PROTECTED]; Tue, 14 Feb 2006 15:21:21 + (GMT) From: fyodor [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: eBook.pdf MIME-Version: 1.0 Content-Type: multipart/mixed; boundary==_NextPart_4.75740075111389E-02 Message-Id: [EMAIL PROTECTED] Date: Tue, 14 Feb 2006 15:21:21 + (GMT) Thanks, -Mark ___ 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] Anybody else getting trojans from someone masquerading as fyodor?
Just to be clear and because I've received a few replies, I realize that fyodor didn't send these messages. I wasn't born yesterday ;) I found the coincidence of me joining the list a week ago and someone forging trojans to me from fyodor to be interesting and I was wondering if anyone else was receiving the same forgeries. Thanks -Mark ___ 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] Interception of SSL 3 communication
I am trying to perform a man in the middle attack on a local client application. The application client (VB application) uses a client side certificate located on a smart card (GEMPLUS) to encrypt co communication with the server (Java servlet). AllI know is that the application accesses a url like this: https://www.thesite.comvia SSL 3. I don't have the source of the client code, but I would like to view/alter the communication in some way. When the card is inserted IE is able to view the certificate, and export it in several formats. I tried Paros to intercept the communication but I couldn't meet its certificate requirements. Thanks to anyone who can help me intercept the communication. ___ 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] blocking Google Desktop
Check out flowbits. The first rule would get flowbits:noalert; flowbits:set,google.user.agent; And the second rule would get flowbits:isset,google.user.agent; That way the alert for the first rule would be suppressed and the second rule would only trigger if the first one occured previously. On 2/13/06, Michael Holstein [EMAIL PROTECTED] wrote: First, I made a mistake in the version number. The current/new one is version 3 (the one that uploads your data to Google) I've been experimenting with Snort sigs to detect this. Google Desktop uses a unique user-agent (I got a tip about this from another user at full-disclosure -- thanks Charles!) : User-Agent: Mozilla/4.0 (compatible; Google Desktop) So here is a snort sig for that ... alert tcp $HOME_NET any - $EXTERNAL_NET 80 (msg: BLEEDING-EDGE Google Desktop User-Agent Detected; flow: to_server,established; content:User-Agent\: Mozilla/4.0 (compatible\; Google Desktop); nocase; classtype: policy-violation; sid: 301; rev:1; ) That sig would at least let you know who's using it, but blocking that traffic wouldn't do anything except prevent the RSS feeds (news, weather, etc) from loading. Now, for the file-specific stuff, since that's all done over SSL to google.com : Upon examining the SSL/TLS session setup, I wrote this one to flag the certificate Google is using (from Thwarte). This will probably change when they change/renew their certificates. alert tcp $EXTERNAL_NET 443 - $HOME_NET 1024:65535 (msg: BLEEDING-EDGE Google SSL key exchange; flow: from_server,established; content:|30 36 30 36 30 37 32 32 31 32 35 34 5A 30 68 31|; rawbytes; content:|77 77 77 2E 67 6F 6F 67 6C 65 2E 63 6F 6D|; rawbytes; classtype:policy-violation; sid: 302; rev:1; ) Note that this also flags logons to gmail. The fetches with the Google Desktop user-agent happen first when the application is started -- then you get the SSL setup for any new data to be uploaded to Google's servers. Unfortunately, the dynamic/activate stuff in snort dosen't let you do an alert action after an activate -- because it's designed to just dump the next (n) packets. If there was a good way to chain the two rules together -- to say after seeing 1, do REACT on #2 you could reliably kill any SSL/TLS sessions from somebody running Google Desktop, thus preventing the upload of anything. Thoughts? Michael Holstein CISSP GCIA Cleveland State University ___ 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 - 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] blocking Google Desktop
The first rule would get flowbits:noalert; flowbits:set,google.user.agent; And the second rule would get flowbits:isset,google.user.agent; Is that global (if #1, then always #2), or is it per-IP ? I verified I can block the SSL session setup using the snort sig I posted the other day .. but it kills any Google SSL (gmail, groups, etc.) .. which is fine, provided I can only block google SSL to users that are running the desktop. ~Mike. ___ 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] iDefense Security Advisory 02.14.06: Microsoft Windows Media Player Plugin Buffer Overflow Vulnerability
Microsoft Windows Media Player Plugin Buffer Overflow Vulnerability iDefense Security Advisory 02.14.06 http://www.idefense.com/intelligence/vulnerabilities/display.php?id=393 February 14, 2006 I. BACKGROUND Windows Media Player is a full featured Audio/Visual playback application offered by Microsoft. The Windows Media Player package also contains a plugin component that can be utilized from most modern browsers such as Internet Explorer, Opera, Firefox, and Netscape. More information on the product can be found from the Microsoft Windows Media Web Site: http://www.microsoft.com/windows/windowsmedia/default.aspx II. DESCRIPTION Windows Media Player (WMP) can be launched as a plugin in popular browsers to view Windows Media Player file types from web pages. A vulnerability in the Windows Media Player plugin can be triggered from several popular browsers such as FireFox and Netscape. The issue specifically can be triggered when certain browsers launch it with an overly long embed src tag from a malicious html page. Upon successful exploitation, attackers will be able to overwrite a Structured Exception Handler (SEH) address and execute arbitrary code on the system. The vulnerability specifically lays in npdsplay.10001040 where a user supplied string is copied to a stack based buffer: 1000171A C1E9 02 SHR ECX,2 1000171D F3:A5REP MOVS DWORD PTR ES:[EDI],DWORD PTR DS:[ESI] 1000171F 8BC8 MOV ECX,EAX III. ANALYSIS Successful exploitation of this vulnerability allows attackers to execute code within the context of the currently logged in user. The victim would have to visit a malicious website using Firefox or Netscape browsers and have Windows Media Player installed. With properly crafted input the attacker is able to execute code of his choice. Due to unicode translations, shellcode characters are somewhat limited to character code values below 0x80. Successful exploitation of this vulnerability is not significantly impacted by this limitation. IV. DETECTION This vulnerability has been tested with Windows Media Player 9 and 10, when launched from the following browsers: * Firefox .9 - Current * Netscape 8 Other versions of Windows Media Player may be vulnerable. This exploit may be able to be triggered from browsers other than those listed above. This condition does not appear to be able to be launched from Internet Explorer or Opera browsers. V. WORKAROUND This exploit can only be triggered if Windows Media Player is set as the default application to launch media file extensions. Exploitation can be prevented by remapping any media file extensions typically handled by Windows Media Player to an alternative application. This exploit can also only be launched from specific browsers. Users could use an alternative browser until an official vendor supplied patch is available. VI. VENDOR RESPONSE The vendor has issued the following security advisory for this issue: http://www.microsoft.com/technet/security/bulletin/MS06-006.mspx VII. CVE INFORMATION The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2006-0005 to this issue. This is a candidate for inclusion in the CVE list (http://cve.mitre.org), which standardizes names for security problems. VIII. DISCLOSURE TIMELINE 08/31/2005 Initial vendor notification 08/31/2005 Initial vendor response 02/14/2006 Coordinated public disclosure IX. CREDIT This vulnerability was submitted to iDefense by John Cobb, as well as a second researcher who wishes to remain anonymous. Get paid for vulnerability research http://www.idefense.com/poi/teams/vcp.jsp Free tools, research and upcoming events http://labs.idefense.com X. LEGAL NOTICES Copyright © 2006 iDefense, Inc. Permission is granted for the redistribution of this alert electronically. It may not be edited in any way without the express written consent of iDefense. If you wish to reprint the whole or any part of this alert in any other medium other than electronically, please email [EMAIL PROTECTED] for permission. Disclaimer: The information in the advisory is believed to be accurate at the time of publishing based on currently available information. Use of the information constitutes acceptance for use in an AS IS condition. There are no warranties with regard to this information. Neither the author nor the publisher accepts any liability for any direct, indirect, or consequential loss or damage arising from use of, or reliance on, this information. ___ 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] blocking Google Desktop
I believe it is per TCP session, but don't quote me on that. Actually now that i think about it, if it indeed is per TCP session then the second rule will not trigger, since the SSL connection will be a part of a different session. I am not 100% sure though. Try it out and let us know. You might want to post to snort-sigs or snort-users and see if they are more helpful. On 2/14/06, Michael Holstein [EMAIL PROTECTED] wrote: The first rule would get flowbits:noalert; flowbits:set,google.user.agent; And the second rule would get flowbits:isset,google.user.agent; Is that global (if #1, then always #2), or is it per-IP ? I verified I can block the SSL session setup using the snort sig I posted the other day .. but it kills any Google SSL (gmail, groups, etc.) .. which is fine, provided I can only block google SSL to users that are running the desktop. ~Mike. ___ 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] XSS and SQL injection in sNews
Official page : http://www.solucija.com/home/snews/
XSS in comments :
just post some comment with scriptalert('XSS TEST by
securitydot.net');/script
FIX : put this on 423 line
$r = str_replace (,lt,$r);
$r = str_replace (,lg,$r);
Injection through categories : index.php?category=1%20or%201=2
FIX : put this on 313 line
if (ereg('^[0-9]*$' , $category))
Injection through id : index.php?id=0%20or%201=2
FIX : put this on 175 line
if (ereg('^[0-9]*$' , $id)) {
--
Securitydot.net
joffer and DrFrancky
___
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] Fun with Foundstone
Things for a security company not to do in a webapp: 1. Do not auto-populate form fields on the page with customer names. 2. If you ignore rule number 1, don't use a simple, predictable id for said auto-population. https://download.foundstone.com/?o=^2155 Rinse, increment, and repeat for a list of Foundstone customers...or at least a list of companies they've let download software. Now that's just plain sloppy. 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] Tracking with etags
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 First, sorry if this has been mentioned before. I've searched and haven't found any mention, but it seems too obvious to have not already been reported. Basically, client gets etag from server, client sends etag to server next time it connects, server can associate client. Might not sound significant, but if Gmail - for instance - gives people Etag's, they - and anyone listening in on the connection - can associate unanonnimized accounts with anonymized accounts. I tested this on tor + privoxy and it worked. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (OpenBSD) iQIVAwUBQ/IDmsLXg8DOh72JAQK94hAAhCS1r7b6R1xJa9QuGD2MNJLZbNPuZxbc 4d9R/5wV2Xa2/UDbGwjAoX2kZNsje9X+tLwIcprSp1sUavXnYZZZC2GJblvmc3j7 UDAVo3Ge44U4GFTP03l86DPWD18d6PmkYkrdUkOJfCiaGDSnhlsOjvywFUqOIvDq cLuDrKXYn2XCu1wEG5BUPVKQSRdIvyK4lsIEGUlUgVCsp5H0ComeVIOANcNUxwrW GGnvh7X+6lzbpLAsb89QME3I8+2CcHhGjkbGr47R/eBcjU1zGKObbVS+4McYgJaY VL5hNnTUgst4a+m3mm6dPSm+n/MDurnXVq+AvWOf0YA6yjZO+ve6vUQsfrfujN2d 3p+4xj5cNWS1AMpF9/0lcSFwOr43hfOG4xePbdyXOppMeSTMDGf2ApuPvpjn4jKg nGhDqq4Ho2DZDnoMYhYtdeW6dB7QGxluChmC0Mflnaar1EBJyUrqppPfDPPK8OLG /8ZVgJo3qR+ruKGpfzC7pKP43Q8gMRUWu6YuPg92SIojgd2mJXfR2zlRQkgZeg71 CO+use+wCeuFMw0ICA64dfwIJrl7EoAaNTTAaKgoy8Wiklh4y8jN3xclSPqv1QWv kKqTA5ZeTlzxZyM1lLHJ05ruBk1WUBQ7TKijEX67hrQrkBFPw3yB1clHbwLotVjV ls51uf4YtAM= =pvn0 -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] Re: Fun with Foundstone
[EMAIL PROTECTED] wrote: Things for a security company not to do in a webapp: 1. Do not auto-populate form fields on the page with customer names. 2. If you ignore rule number 1, don't use a simple, predictable id for said auto-population. https://download.foundstone.com/?o=^2155 LOL, blocked already! Rinse, increment, and repeat for a list of Foundstone customers...or at least a list of companies they've let download software. ... or at least a list of a million-and-one variants on M. Mouse and Noah Body ... ... nearly _all_ of whom appear to live in Beverley Hills. cheers, DaveK -- Can't think of a witty .sigline today ___ 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] Fun with Foundstone
And while we're at it... https://download.foundstone.com/?o=;scriptalert(xss)/script PGP.sig Description: This is a digitally signed message part ___ 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] Fun with Foundstone
[EMAIL PROTECTED] wrote: https://download.foundstone.com/?o=^2155 Now that's just plain sloppy. But at least it's SSL-secured. ___ 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] Comment spam: drive-by sites, domains and spyware - analysis, samples and facts
Warning: this post is being X-posted. Blog/web spam is not the next spam medium, it is spam plain and simple. People, including some anti spam experts, just don't realize how big it all is. It's not only about spam, it is about spyware, bots and breaking into computers. How about I provide with some facts? Below are some selected spam samples from one of the high-traffic blogs I help maintain. Some of them are included for the repeat-offenders point being made, showing the different IP addresses that attacked us from a botnet/proxy list of compromised (broken into) systems. NOTE: The URL's quoted are NOT safe. DO NOT go there unless you know what you are doing. Responsibility is yours alone. As an example, take a look at: http://w ww.hackologie.tk/ It is a site for a drive-by. Spyware you say? Find out. :) Below, further in the text, I start an analysis, showing hundreds of DNS RR's for just one of the IP's you will find looking at the A record for that site. This is indeed one of the uses for the new black-list some of us are creating. Cooperative effort to compare spams across different blogs, analyze them, find distinct groups and block them, as well as terminate their domain names. FURTHER - it's a nice way to find their new Trojan horses and spyware, as well as their new domains. These samples will then be reported to anti virus and anti spyware vendors, as much like we will work to terminate the domains - we will also work to make their malware useless. The malware proves that most of these guys are not just annoying spammers abusing our services, AUP's, users and privacy. It proves they break into computers as well as try and break into ours. Anti spam projects will get a feed so that whatever medium they spam, we will all cooperate to kick them back. So far some of the biggest blogging sites online are enlisted on our effort (which is not limited to this), we will see what happens. My previous (most recent) post on this subject can be found here: http://blogs.securiteam.com/index.php/archives/285 This post can be found here: http://blogs.securiteam.com/index.php/archives/290 Some more analysis on the bad site I spoke of above as an example: A full analysis will take time I don't have, so let's just show a few teasers to get you curious! Due to restrictions in Dot TK's Privacy Statement personal information about the user of the domain name cannot be released. ^^^ Ain't that convenient? Domain TypeClass TTL Answer hackologie.tk. MX IN 86400 mx-host.dot.tk. [Preference = 20] hackologie.tk. A IN 300 62.129.131.38 hackologie.tk. A IN 300 217.115.203.21 hackologie.tk. A IN 300 195.20.32.104 hackologie.tk. A IN 300 209.172.59.193 hackologie.tk. A IN 300 217.119.57.19 tk.NS IN 86400 root-g.taloha.tk. tk.NS IN 86400 ns-a.taloha.tk. tk.NS IN 86400 ns-b.taloha.tk. tk.NS IN 86400 ns-c.taloha.tk. tk.NS IN 86400 root-a.taloha.tk. tk.NS IN 86400 root-b.taloha.tk. tk.NS IN 86400 root-c.taloha.tk. tk.NS IN 86400 root-d.taloha.tk. tk.NS IN 86400 root-e.taloha.tk. tk.NS IN 86400 root-f.taloha.tk. root-g.taloha.tk. A IN 21600 217.68.243.17 ns-a.taloha.tk.A IN 21600 62.41.22.202 ns-b.taloha.tk.A IN 21600 195.11.245.84 ns-c.taloha.tk.A IN 21600 216.38.132.90 root-a.taloha.tk. A IN 21600 194.109.152.138 root-b.taloha.tk. A IN 21600 195.20.32.102 root-c.taloha.tk. A IN 21600 207.36.228.217 root-d.taloha.tk. A IN 21600 217.199.176.121 root-e.taloha.tk. A IN 21600 66.36.231.236 root-f.taloha.tk. A IN 21600 202.125.44.173 Just a FEW of the DNS RR's pointing to just one of the IP addresses: www.*.tk A 62.129.131.38 www.*.tk A 62.129.131.38 www.-fctwente-.tkA 62.129.131.38 www.-beach-.tk A 62.129.131.38 www.-erki-.tkA 62.129.131.38 www.atletiek2000.tk A 62.129.131.38 www.beveren2000.tk A 62.129.131.38 www.cj800.tk A 62.129.131.38 www.boca80.tkA 62.129.131.38 bomma80.tk A 62.129.131.38 www.armenia90.tk A 62.129.131.38 em0.tk A 62.129.131.38 www.stropkaai31.tk A 62.129.131.38 www.piaa1.tk A 62.129.131.38 www.devalkb1.tk A 62.129.131.38 www.brambo1.tk A 62.129.131.38 www.ignis1.tkA 62.129.131.38 www.thesims-2.tk A 62.129.131.38 www.biot2002.tk A 62.129.131.38 www.5voor12.tk A 62.129.131.38 www.boelie-v32.tkA 62.129.131.38 www.jordistylertje-b42.tkA 62.129.131.38 www.seca2.tk A
[Full-disclosure] [EEYEB-20051017] Windows Media Player BMP Heap Overflow
EEYEB-20051017 Windows Media Player BMP Heap Overflow Release Date: February 14, 2006 Date Reported: October 17, 2005 Patch Development Time (In Days): 60 Severity: High (Remote Code Execution) Vendor: Microsoft Systems Affected: Microsoft Windows Media Player 7.1 through 10 Windows NT 4.0 Windows 98 / ME Windows 2000 SP4 Windows XP SP1 / SP2 Windows 2003 eEye ID: EEYEB-20051017 CVE: CVE-2006-0006 Overview: eEye Digital Security has discovered a critical vulnerability in Windows Media Player. The vulnerability allows a remote attacker to reliably overwrite heap memory with user-controlled data and execute arbitrary code in the context of the user who executed the player. Windows Media Player has a security issue within Media Player versions 7.1 through 10 on all Windows os's. This flaw is a heap overflow, and an attacker can use multiple vectors to exploit it. Attackers can create .asx files and open them with a URL, use activex embeded in an HTML page or create a Media Player skin file. Technical Description: Windows Media Player can play bit map format files, such as a .bmp file and use Windows Media Player (WMP) to decode the .dll process bmp file. But it can't correctly process a bmp file which declares it's size as 0. In this case, WMP will allocate a heap size of 0 but in fact, it will copy to the heap with the real file length. So a special bmp file that declares it's size as 0 will cause the overflow. When changing the size to 0, WMP will allocate the heap of the new function, so actually it will allocate 0x2*8(heap) sized heap. When we copy the date is will check two conditions: 1. less than the size - the bmp head, this is 0-0xe(the bmp head size) = 0xfff2 2. less than 0x1000 So if the real file size is less than 0x1000, it will copy the real date size to the 0x2*8 heap, if the real file size is larger than 0x1000, it will copy the first 0x1000 to the 0x2*8 heap. Protection: Retina Network Security Scanner has been updated to identify this vulnerability. Blink - Endpoint Vulnerability Prevention - preemptively protects from this vulnerability. Vendor Status: Microsoft has released a patch for this vulnerability. The patch is available at: http://www.microsoft.com/technet/security/bulletin/ms06-005.mspx Credit: Fang Xing Copyright (c) 1998-2006 eEye Digital Security Permission is hereby granted for the redistribution of this alert electronically. It is not to be edited in any way without express consent of eEye. If you wish to reprint the whole or any part of this alert in any other medium excluding electronic medium, please email [EMAIL PROTECTED] for permission. Disclaimer The information within this paper may change without notice. Use of this information constitutes acceptance for use in an AS IS condition. There are no warranties, implied or express, with regard to this information. In no event shall the author be liable for any direct or indirect damages whatsoever arising out of or in connection with the use or spread of this information. Any use of this information is at the user's own risk. ___ 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] Maxxuss does it again! OSx86 10.4.4 Security Broken!
*Maxxuss does it again! OSx86 10.4.4 Security Broken! http://www.hackinthebox.org/modules.php?op=modloadname=Newsfile=articlesid=19342mode=threadorder=0thold=0* Happy Valentines Day... from Maxxuss. The hacking guru has announced preliminary patches for Apple's latest release of OS X for Intel, version 10.4.4. According to his website, ___ 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] [SECURITY] [DSA 972-1] New pdfkit.framework packages fix denial of service
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Debian Security Advisory DSA 972-1 [EMAIL PROTECTED] http://www.debian.org/security/ Martin Schulze February 15th, 2006 http://www.debian.org/security/faq - -- Package: pdfkit.framework Vulnerability : buffer overflows Problem type : local (remote) Debian-specific: no CVE ID : CVE-2006-0301 SuSE researchers discovered heap overflow errors in xpdf, the Portable Document Format (PDF) suite, which is also present in pdfkit.framework, the GNUstep framework for rendering PDF content, and which can allow attackers to cause a denial of service by crashing the application or possibly execute arbitrary code. The old stable distribution (woody) does not contain pdfkit.framework packages. For the stable distribution (sarge) these problems have been fixed in version 0.8-2sarge2. For the unstable distribution (sid) these problems have been fixed in version 0.8-4 by switching to poppler. We recommend that you upgrade your pdfkit.framework package. Upgrade Instructions - wget url will fetch the file for you dpkg -i file.deb will install the referenced file. If you are using the apt-get package manager, use the line for sources.list as given below: apt-get update will update the internal database apt-get upgrade will install corrected packages You may use an automated update by adding the resources from the footer to the proper configuration. Debian GNU/Linux 3.1 alias sarge - Source archives: http://security.debian.org/pool/updates/main/p/pdfkit.framework/pdfkit.framework_0.8-2sarge2.dsc Size/MD5 checksum: 725 7f73aebe47f6276e59274a791dbf9f1d http://security.debian.org/pool/updates/main/p/pdfkit.framework/pdfkit.framework_0.8-2sarge2.diff.gz Size/MD5 checksum: 6014 04f72fb2031311bbf6bf433e440a18e7 http://security.debian.org/pool/updates/main/p/pdfkit.framework/pdfkit.framework_0.8.orig.tar.gz Size/MD5 checksum: 1780533 7676643ff78a0602c10bfb97fe0bd448 Alpha architecture: http://security.debian.org/pool/updates/main/p/pdfkit.framework/pdfkit.framework_0.8-2sarge2_alpha.deb Size/MD5 checksum: 1822048 8321e3be8a859346ecbe90a5d80083ce AMD64 architecture: http://security.debian.org/pool/updates/main/p/pdfkit.framework/pdfkit.framework_0.8-2sarge2_amd64.deb Size/MD5 checksum: 1796860 5776df0db71190ae3f8557665079dfef ARM architecture: http://security.debian.org/pool/updates/main/p/pdfkit.framework/pdfkit.framework_0.8-2sarge2_arm.deb Size/MD5 checksum: 1756204 6aa00d8b3cb35e825bd57a531f1d8bce Intel IA-32 architecture: http://security.debian.org/pool/updates/main/p/pdfkit.framework/pdfkit.framework_0.8-2sarge2_i386.deb Size/MD5 checksum: 1750532 4c22f6c78b52e7ce2b0ae0e1eaf002d6 Intel IA-64 architecture: http://security.debian.org/pool/updates/main/p/pdfkit.framework/pdfkit.framework_0.8-2sarge2_ia64.deb Size/MD5 checksum: 1981414 cad4fb0db7635253e96995f3b6e651ed HP Precision architecture: http://security.debian.org/pool/updates/main/p/pdfkit.framework/pdfkit.framework_0.8-2sarge2_hppa.deb Size/MD5 checksum: 1862592 330d89f3ee48fed31d74a726cfaf6fcc Motorola 680x0 architecture: http://security.debian.org/pool/updates/main/p/pdfkit.framework/pdfkit.framework_0.8-2sarge2_m68k.deb Size/MD5 checksum: 1785864 a15ba6704bf5e19a279721a9f2251e00 Big endian MIPS architecture: http://security.debian.org/pool/updates/main/p/pdfkit.framework/pdfkit.framework_0.8-2sarge2_mips.deb Size/MD5 checksum: 1769322 f718f5753e07c63ce3e724d72550c77c Little endian MIPS architecture: http://security.debian.org/pool/updates/main/p/pdfkit.framework/pdfkit.framework_0.8-2sarge2_mipsel.deb Size/MD5 checksum: 1754998 ebc4a7863f86273a524fd88ae0f3778d PowerPC architecture: http://security.debian.org/pool/updates/main/p/pdfkit.framework/pdfkit.framework_0.8-2sarge2_powerpc.deb Size/MD5 checksum: 1770960 f24d246b3887c84b54cd261ec881c86c IBM S/390 architecture: http://security.debian.org/pool/updates/main/p/pdfkit.framework/pdfkit.framework_0.8-2sarge2_s390.deb Size/MD5 checksum: 1804896 053d61ae24a468c8361f12746f512260 Sun Sparc architecture: http://security.debian.org/pool/updates/main/p/pdfkit.framework/pdfkit.framework_0.8-2sarge2_sparc.deb Size/MD5 checksum: 1780072 f82233c57040266da7ce18bb5708eafe These files will probably be moved into the stable distribution on its next update. - - For apt-get: deb http://security.debian.org/ stable/updates main For dpkg-ftp:
[Full-disclosure] [SECURITY] [DSA 973-1] New OTRS packages fix several vulnerabilities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Debian Security Advisory DSA 973-1 [EMAIL PROTECTED] http://www.debian.org/security/ Martin Schulze February 15th, 2006 http://www.debian.org/security/faq - -- Package: otrs Vulnerability : several Problem type : remote Debian-specific: no CVE IDs: CVE-2005-3893 CVE-2005-3894 CVE-2005-3895 BugTraq ID : 15537 Debian Bug : 340352 Several vulnerabilities have been discovered in otrs, the Open Ticket Request System, that can be exploited remotely. The Common vulnerabilities and Exposures Project identifies the following problems: CVE-2005-3893 Multiple SQL injection vulnerabilities allow remote attackers to execute arbitrary SQL commands and bypass authentication. CVE-2005-3894 Multiple cross-site scripting vulnerabilities allow remote authenticated users to inject arbitrary web script or HTML. CVE-2005-3895 Internally attached text/html mails are rendered as HTML when the queue moderator attempts to download the attachment, which allows remote attackers to execute arbitrary web script or HTML. the old stable distribution (woody) does not contain OTRS packages. For the stable distribution (sarge) these problems have been fixed in version 1.3.2p01-6. For the unstable distribution (sid) these problems have been fixed in version 2.0.4p01-1. We recommend that you upgrade your otrs package. Upgrade Instructions - wget url will fetch the file for you dpkg -i file.deb will install the referenced file. If you are using the apt-get package manager, use the line for sources.list as given below: apt-get update will update the internal database apt-get upgrade will install corrected packages You may use an automated update by adding the resources from the footer to the proper configuration. Debian GNU/Linux 3.1 alias sarge - Source archives: http://security.debian.org/pool/updates/main/o/otrs/otrs_1.3.2p01-6.dsc Size/MD5 checksum: 600 0dd0acec3580502a8f9ecf061ed931de http://security.debian.org/pool/updates/main/o/otrs/otrs_1.3.2p01-6.diff.gz Size/MD5 checksum:15917 f94589b636198b60b76d36ce074dc04f http://security.debian.org/pool/updates/main/o/otrs/otrs_1.3.2p01.orig.tar.gz Size/MD5 checksum: 6639786 8861ace308c6f058b331fbd0e8437f0c Architecture independent components: http://security.debian.org/pool/updates/main/o/otrs/otrs-doc-de_1.3.2p01-6_all.deb Size/MD5 checksum: 3005222 9783133f230474fabdca9b6fa30ea1d9 http://security.debian.org/pool/updates/main/o/otrs/otrs-doc-en_1.3.2p01-6_all.deb Size/MD5 checksum: 2312748 2cd8499682e6b4a5fd3ad7472329a3da http://security.debian.org/pool/updates/main/o/otrs/otrs_1.3.2p01-6_all.deb Size/MD5 checksum: 920580 c29a6b599e31d7b5a847f2f74b658a3c These files will probably be moved into the stable distribution on its next update. - - For apt-get: deb http://security.debian.org/ stable/updates main For dpkg-ftp: ftp://security.debian.org/debian-security dists/stable/updates/main Mailing list: debian-security-announce@lists.debian.org Package info: `apt-cache show pkg' and http://packages.debian.org/pkg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD8t7OW5ql+IAeqTIRAlRzAJ49ZonCnU4U8crIQe1h/2EqkmRlUwCcC2/h Aee8tSb2exVGCkxqvmZVSfs= =d0FA -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/
