Re: [Full-disclosure] EXPLOITS FOR SALE (AUCTION SITE)
On 7/8/07, jt5944-27a [EMAIL PROTECTED] wrote: thank you? okay - thank you for creating this wonderful software that we use. thank you for listening to our defect requests and thank you for addressing them in a meaningful time frame. but thank you for finding bugs? are you on drugs? Drugs? What are you talking about? That is completely off-topic. A hit that bounces back to yourself. they didnt ask you to look for defects. this sounds like those people who paint house numbers on your curb and then want to be paid even through you never said to paint the numbers. or those windshield washers who want you to pay them for smearing your window when you didnt ask for it. the only people who should be paid to find vulnerabilities are the people asked to find vulnerabilities. What about those who come right into your face without even trying to find them? Hey we know how software works. We are all using it and we can think. And sometimes we can track them down too. Don't forget that. And what about those bugs that are created on purpose. A trojanized software or device is too obvious (remember NSA-Crypto AG). But a security bug. Well sorry we made a mistake we are providing a fix. However can serve the same purpose as a trojan horse. They simply can know earlier and fix it later if something goes out of control. That could explain why fixes take so much time sometimes and why there are so many bugs. (Just a theory with some base). No, ppl searching for vulnerabilities should not be only the ones asked to do it. Should be every third party around. And guess what. It is being done right now for whatever purpose. Won't be better if they are sold in the public light than in the shadows? At least we know what is flawed otherwise not even a clue. You are right now only looking at the top of the iceberg. After looking at that website and looking at yahoo messenger 8.1 being on sale I am considering not to use it for a while or put it under a protection layer or use alternatives. Why? Somebody else could have found that too and could be using it. And if somebody asks my opinion to install some soft listed there I would tell them not to do it because it is not safe. That means security after all. And if they make money. Then good. Somebody that knows how to find them was rewarded and encouraged to do more research. Something you forgot to do before distributing to ppl. Yep cutting the bill putting ppl under risk. That reminds me cars that exploded because of bad design and ppl becoming ill with cancer or something else by feeding chickens with hormones and stuff like that. On the other side I am pretty sure that those grey foreigners you all talk about already have their own working teams and already have undisclosed technology. The one you don't know. You better favor research so you can put the finger on the hole before water begins to flow. But using your very own who asked you. I could reply also to you. Who asked you to make a software/service/device? Yet more who asked you to make something that is broken? But yet more who asked you to make something that is broken and that you sell/provide as if it is good? But then I don't want to reply to you that way because I understand that things needs to be done even if nobody asks for them. That also applies to security research. Hey many times people doesn't ask because they simply ignore things. And about the windshield washers. Well you could understand that they are usually ppl with extreme need for some cash (otherwise they wouldn't be doing that) many times just to eat while you drive your fancy car. You could be more human than that. If I were in that situation and I have some cash and some of them smear my windshield I would not be poorer/richer for giving them something. That would make me a lot better than you. After all they are working, not robbing/assaulting ppl on the streets or hitting your neck to steal your wallet. Or do you prefer that? They have the right to live too and you are pushing them to find desperate alternatives. That's what is wrong. And since you are simply taking the example to compare it with security research then take it back to the original example, compare and see for yourself. should we pay burglars for breaking into our homes? No we could pay key makers that know when your lock can be broken so a burglar doesn't break into your home. That's quite different. You will be paying for your own security. Hey burglars are already paying for that and you are only complaining. Doing it is not going to change anything. Don't you think is better to try new or better alternatives? Even if that means that you will make a little less money or that it will cost you a little extra? and what about open source projects? should nonprofit groups be forced to pay for defects that they never asked people to look for? Good point but I already have a couple of answers to you because that crossed my mind too. 1- Open Source != 0 profit.
Re: [Full-disclosure] The Auction Site made Forbes.
In a way a larger company (beyond idefense/tippingpoint) getting involved will be to our advantage. There hasn't been a high profile lawsuit against a vuln researcher for finding and selling an 0day at this point (that I can think of) and it's only a matter of time before it happens. A company with a closed source product can claim EULA agreement violations as well as IP violations. While they may not win the lawsuit they will punish you with lawyer fee's potentially bankrupting you and I'd rather not be the one to test the theory. By working with an established company as a researcher you may be offered some sort of legal protection provided by the terms of the agreement with the company you're selling it to, if said vulnerable company came after you. Regards, - Robert http://www.cgisecurity.com/ Website and Application security news http://www.webappsec.org/ The Web Application Security Consortium Hadn't thought about it that way... ;] Let the fun begin. On 7/9/07 4:25 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Mon, 09 Jul 2007 15:50:16 EDT, Simon Smith said: Guys, Thought you might like to see this: http://www.forbes.com/home/security/2007/07/06/security-software-hacking-tech -security-cx_ag_0706vulnmarket.html Just fsck'ing great. Now we'll have venture capitalists and arbitrage specialists and all that ilk wanting a piece of the action. You thought this was all morally murky *before*, you ain't seen nothing yet. :) ___ 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] Full-Disclosure Digest, Vol 29, Issue 14
On Monday 09 July 2007, [EMAIL PROTECTED] wrote: Message: 1 Date: Sun, 8 Jul 2007 07:25:34 -0400 From: Paul Melson [EMAIL PROTECTED] Subject: Re: [Full-disclosure] EXPLOITS FOR SALE (AUCTION SITE) To: [EMAIL PROTECTED] [EMAIL PROTECTED] Cc: full-disclosure@lists.grok.org.uk Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 7/6/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Note that the Internet as we know it really took off when the pr0n industry started using it in a big way. They've always been early adopters of new technology... Wait, so are we waiting for the Internet porn industry to get on board with the auctioning of exploits? I'm so confused. Hey Paul, More likely the purchase of... although all this talk about being noble makes me think about Hamlet. To Hack or NOT To Hack. That is the question. Whether tis nobler to exploit and disclose... or to skip litigious misery and sell the damn thing on zeBay... anonymously of course. Although how to anonymize monetary transaction... that is truly and art. @ -- YXJ0aXN0cyB1c2UgbGllcyB0byB0ZWxsIHRoZSB0cnV0aCB3aGlsZSBwb2xpdGljaWFucyB1c2UgdGhlbSB0byBjb3ZlciBpdCB1cAo= pgp8XkjF6EJZH.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] Google/Orkut Authentication/Session Management Issue PoC - Interim Results
If you sign into orkut.com then enter orkut in the filter box then you will see some orkut cookies. Look for orkut_state in www.orkut.com site. It will work if you are logged in. if you log out orkut_state cookie disappears but the session remains active in orkut.com server. So a big problem is happening in orkut. when attackers stole some cookies using XSS attacks earlier they were misusing the accounts after owner of account logged out. This problem is happening because after owner of account logged out the session remained active. In other sites like yahoo this is not possible because the session deactivates in the server after owner of account logs out. Thanks Joseph --- Deeþàn Chakravarthÿ [EMAIL PROTECTED] wrote: It works great. But I am not able to find a similar cookie for my account. Am I missing something ? Thanks Deepan Joseph Hick wrote: This is the interim result of a proof of concept for Google Authentication issues posted in the threads... 1.) http://lists.grok.org.uk/pipermail/full-disclosure/2007-June/064143.html (Orkut Server Side Management Error by Susam Pal Vipul Agarwal) 2.) http://lists.grok.org.uk/pipermail/full-disclosure/2007-June/064300.html (Google Re-authentication Bypass by Susam Pal) A session was created in Orkut at about Sat Jun 30 20:30 UTC 2007. Between June 30 and now many have hijacked this session and logged out many times but the session is alive today as verified on Sun Jul 8 at 09:43:10 UTC 2007. The cookie for this PoC session is ... Name: orkut_state Cookie: ORKUTPREF=ID=11190574376736842125:INF=0:SET=111236436:LNG=1:CNT=0:RM=0:USR=aGlqYWNrbWVwbGVhc2VAZ29vZ2xlbWFpbC5jb20=:PHS=:TS=1183210062:LCL=en-US:NET=1:TOS=1:GC=DQAAAIMrC-mJYqsrCOnv8uVQHdFUccRFQX8-ibRerEzrie5sOWNc06zs4z4fMNpovLUyRcNXHwxk8WzY6Z6SmvxcSmL1hAW4Mrdvazzkssq5VjSO70oE1HSFR4KOkSb3ZLg-U7k0x8c7ZuLHwu_qY2Umy8oobckg9UctWXYd1qoerXUTzsFSuLNXHdiAEVCSw7fUO00:PE=aGlqYWNrbWVwbGVhc2VAZ29vZ2xlbWFpbC5jb20=:GTI=0:GID=aGlqYWNrbWVwbGVhc2VAZ29vZ2xlbWFpbC5jb20=:VER=2:S=1Ah7VcA0JetHQ0Mgyfp4Jb6meXw=: Domain: .www.orkut.com Path: / Send for: Any type of session Expires: Expire at end of session This proves that the session remains alive for at least 7 days after logging out. Steps to verify this... 1.) Open Firefox, etc. which allows cookie editing. This extension is required... https://addons.mozilla.org/en-US/firefox/addon/573 2.) Set the given cookie. 3.) Try to visit http://www.orkut.com/Home.aspx 4.) You will be automatically logged in with my account. It will not ask for any user-name or password. 5.) Logout 6.) Repeat steps 1. to 4. You can log in again. I want to see how long this session remains alive after multiple logout. If you try this POC leave a message in the scrapbook of the account here ... http://www.orkut.com/Scrapbook.aspx Thanks Joseph Get the free Yahoo! toolbar and rest assured with the added security of spyware protection. http://new.toolbar.yahoo.com/toolbar/features/norton/index.php ___ 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] Google/Orkut Authentication/Session Management Issue PoC - Interim Results
Joseph Hick wrote: If you sign into orkut.com then enter orkut in the filter box then you will see some orkut cookies. Look for orkut_state in www.orkut.com site. It will work if you are logged in. if you log out orkut_state cookie disappears but the session remains active in orkut.com server. So a big problem is happening in orkut. when attackers stole some cookies using XSS attacks earlier they were misusing the accounts after owner of account logged out. This problem is happening because after owner of account logged out the session remained active. In other sites like yahoo this is not possible because the session deactivates in the server after owner of account logs out. Hi Joseph, Thanks, I was looking for the cookie after logging off. Thanks Deepan --- Deeþàn Chakravarthÿ [EMAIL PROTECTED] wrote: It works great. But I am not able to find a similar cookie for my account. Am I missing something ? Thanks Deepan Joseph Hick wrote: This is the interim result of a proof of concept for Google Authentication issues posted in the threads... 1.) http://lists.grok.org.uk/pipermail/full-disclosure/2007-June/064143.html (Orkut Server Side Management Error by Susam Pal Vipul Agarwal) 2.) http://lists.grok.org.uk/pipermail/full-disclosure/2007-June/064300.html (Google Re-authentication Bypass by Susam Pal) A session was created in Orkut at about Sat Jun 30 20:30 UTC 2007. Between June 30 and now many have hijacked this session and logged out many times but the session is alive today as verified on Sun Jul 8 at 09:43:10 UTC 2007. The cookie for this PoC session is ... Name: orkut_state Cookie: ORKUTPREF=ID=11190574376736842125:INF=0:SET=111236436:LNG=1:CNT=0:RM=0:USR=aGlqYWNrbWVwbGVhc2VAZ29vZ2xlbWFpbC5jb20=:PHS=:TS=1183210062:LCL=en-US:NET=1:TOS=1:GC=DQAAAIMrC-mJYqsrCOnv8uVQHdFUccRFQX8-ibRerEzrie5sOWNc06zs4z4fMNpovLUyRcNXHwxk8WzY6Z6SmvxcSmL1hAW4Mrdvazzkssq5VjSO70oE1HSFR4KOkSb3ZLg-U7k0x8c7ZuLHwu_qY2Umy8oobckg9UctWXYd1qoerXUTzsFSuLNXHdiAEVCSw7fUO00:PE=aGlqYWNrbWVwbGVhc2VAZ29vZ2xlbWFpbC5jb20=:GTI=0:GID=aGlqYWNrbWVwbGVhc2VAZ29vZ2xlbWFpbC5jb20=:VER=2:S=1Ah7VcA0JetHQ0Mgyfp4Jb6meXw=: Domain: .www.orkut.com Path: / Send for: Any type of session Expires: Expire at end of session This proves that the session remains alive for at least 7 days after logging out. Steps to verify this... 1.) Open Firefox, etc. which allows cookie editing. This extension is required... https://addons.mozilla.org/en-US/firefox/addon/573 2.) Set the given cookie. 3.) Try to visit http://www.orkut.com/Home.aspx 4.) You will be automatically logged in with my account. It will not ask for any user-name or password. 5.) Logout 6.) Repeat steps 1. to 4. You can log in again. I want to see how long this session remains alive after multiple logout. If you try this POC leave a message in the scrapbook of the account here ... http://www.orkut.com/Scrapbook.aspx Thanks Joseph Get the free Yahoo! toolbar and rest assured with the added security of spyware protection. http://new.toolbar.yahoo.com/toolbar/features/norton/index.php ___ 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] Google/Orkut Authentication/Session Management Issue PoC - Interim Results
my firnd got my session cookie a day before yesterdy.. is there any method i can stop him by using my orkut account? On 7/10/07, Deeþàn Chakravarthÿ [EMAIL PROTECTED] wrote: Joseph Hick wrote: If you sign into orkut.com then enter orkut in the filter box then you will see some orkut cookies. Look for orkut_state in www.orkut.com site. It will work if you are logged in. if you log out orkut_state cookie disappears but the session remains active in orkut.com server. So a big problem is happening in orkut. when attackers stole some cookies using XSS attacks earlier they were misusing the accounts after owner of account logged out. This problem is happening because after owner of account logged out the session remained active. In other sites like yahoo this is not possible because the session deactivates in the server after owner of account logs out. Hi Joseph, Thanks, I was looking for the cookie after logging off. Thanks Deepan --- Deeþàn Chakravarthÿ [EMAIL PROTECTED] wrote: It works great. But I am not able to find a similar cookie for my account. Am I missing something ? Thanks Deepan Joseph Hick wrote: This is the interim result of a proof of concept for Google Authentication issues posted in the threads... 1.) http://lists.grok.org.uk/pipermail/full-disclosure/2007-June/064143.html (Orkut Server Side Management Error by Susam Pal Vipul Agarwal) 2.) http://lists.grok.org.uk/pipermail/full-disclosure/2007-June/064300.html (Google Re-authentication Bypass by Susam Pal) A session was created in Orkut at about Sat Jun 30 20:30 UTC 2007. Between June 30 and now many have hijacked this session and logged out many times but the session is alive today as verified on Sun Jul 8 at 09:43:10 UTC 2007. The cookie for this PoC session is ... Name: orkut_state Cookie: ORKUTPREF=ID=11190574376736842125:INF=0:SET=111236436:LNG=1:CNT=0:RM=0:USR=aGlqYWNrbWVwbGVhc2VAZ29vZ2xlbWFpbC5jb20=:PHS=:TS=1183210062:LCL=en-US:NET=1:TOS=1:GC=DQAAAIMrC-mJYqsrCOnv8uVQHdFUccRFQX8-ibRerEzrie5sOWNc06zs4z4fMNpovLUyRcNXHwxk8WzY6Z6SmvxcSmL1hAW4Mrdvazzkssq5VjSO70oE1HSFR4KOkSb3ZLg-U7k0x8c7ZuLHwu_qY2Umy8oobckg9UctWXYd1qoerXUTzsFSuLNXHdiAEVCSw7fUO00:PE=aGlqYWNrbWVwbGVhc2VAZ29vZ2xlbWFpbC5jb20=:GTI=0:GID=aGlqYWNrbWVwbGVhc2VAZ29vZ2xlbWFpbC5jb20=:VER=2:S=1Ah7VcA0JetHQ0Mgyfp4Jb6meXw=: Domain: .www.orkut.com Path: / Send for: Any type of session Expires: Expire at end of session This proves that the session remains alive for at least 7 days after logging out. Steps to verify this... 1.) Open Firefox, etc. which allows cookie editing. This extension is required... https://addons.mozilla.org/en-US/firefox/addon/573 2.) Set the given cookie. 3.) Try to visit http://www.orkut.com/Home.aspx 4.) You will be automatically logged in with my account. It will not ask for any user-name or password. 5.) Logout 6.) Repeat steps 1. to 4. You can log in again. I want to see how long this session remains alive after multiple logout. If you try this POC leave a message in the scrapbook of the account here ... http://www.orkut.com/Scrapbook.aspx Thanks Joseph Get the free Yahoo! toolbar and rest assured with the added security of spyware protection. http://new.toolbar.yahoo.com/toolbar/features/norton/index.php ___ 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/
[Full-disclosure] [ MDKSA-2007:143 ] - Updated mplayer packages fix buffer overflow remote vulnerabilities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ___ Mandriva Linux Security Advisory MDKSA-2007:143 http://www.mandriva.com/security/ ___ Package : mplayer Date: July 10, 2007 Affected: 2007.0, 2007.1, Corporate 3.0 ___ Problem Description: Multiple stack-based buffer overflows in stream/stream_cddb.c in MPlayer before 1.0rc1try3 allow remote attackers to execute arbitrary code via a CDDB entry with a long (1) album title or (2) category. Updated packages have been patched to prevent this issue. ___ References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2948 ___ Updated Packages: Mandriva Linux 2007.0: 25e2f7434923c54e22a15817ec58174e 2007.0/i586/libdha1.0-1.0-1.pre8.13.4mdv2007.0.i586.rpm a062d432719daa5ba6f1d5d7307a1ba8 2007.0/i586/mencoder-1.0-1.pre8.13.4mdv2007.0.i586.rpm 17a8adca674bece173ea1ddb6301eaa5 2007.0/i586/mplayer-1.0-1.pre8.13.4mdv2007.0.i586.rpm 27ccf8fa2715d44bfe183603767c56a7 2007.0/i586/mplayer-gui-1.0-1.pre8.13.4mdv2007.0.i586.rpm 0cb86683e6e5c38381fb3cd6ccb62240 2007.0/SRPMS/mplayer-1.0-1.pre8.13.4mdv2007.0.src.rpm Mandriva Linux 2007.0/X86_64: 0eb841778648537762f458fa39e29f6c 2007.0/x86_64/mencoder-1.0-1.pre8.13.4mdv2007.0.x86_64.rpm 51039a3929e9f208fd9e82be957a98de 2007.0/x86_64/mplayer-1.0-1.pre8.13.4mdv2007.0.x86_64.rpm 6288f99b19ff5b871c2183c7c77fea8f 2007.0/x86_64/mplayer-gui-1.0-1.pre8.13.4mdv2007.0.x86_64.rpm 0cb86683e6e5c38381fb3cd6ccb62240 2007.0/SRPMS/mplayer-1.0-1.pre8.13.4mdv2007.0.src.rpm Mandriva Linux 2007.1: ef28e39e802fa8a234f86df2ad95c45c 2007.1/i586/libdha1.0-1.0-1.rc1.11.2mdv2007.1.i586.rpm afe898096241784c90501d8a7a6ccd88 2007.1/i586/mencoder-1.0-1.rc1.11.2mdv2007.1.i586.rpm 9b94c89b98f7f6303bb113873d6c74e2 2007.1/i586/mplayer-1.0-1.rc1.11.2mdv2007.1.i586.rpm 3b4a54447411d32ac010e75943fc5493 2007.1/i586/mplayer-doc-1.0-1.rc1.11.2mdv2007.1.i586.rpm eedbff57903999e78f3ebc31695fd632 2007.1/i586/mplayer-gui-1.0-1.rc1.11.2mdv2007.1.i586.rpm 9aca58cedd97a632d671e550e2abe3ee 2007.1/SRPMS/mplayer-1.0-1.rc1.11.2mdv2007.1.src.rpm Mandriva Linux 2007.1/X86_64: 674516b36f851b06ade955dcc2ccdb6c 2007.1/x86_64/mencoder-1.0-1.rc1.11.2mdv2007.1.x86_64.rpm bf5722fa05f82f79e298830226a995fd 2007.1/x86_64/mplayer-1.0-1.rc1.11.2mdv2007.1.x86_64.rpm 910a0878c17d0f936b6e669032bc6d36 2007.1/x86_64/mplayer-doc-1.0-1.rc1.11.2mdv2007.1.x86_64.rpm c572ce827d290621654bd8c57587f76d 2007.1/x86_64/mplayer-gui-1.0-1.rc1.11.2mdv2007.1.x86_64.rpm 9aca58cedd97a632d671e550e2abe3ee 2007.1/SRPMS/mplayer-1.0-1.rc1.11.2mdv2007.1.src.rpm Corporate 3.0: 34534b724ef48b53d706949f448978ad corporate/3.0/i586/libdha0.1-1.0-0.pre3.14.12.C30mdk.i586.rpm 7f60b9f3ef33ea7e2f131d570c658d10 corporate/3.0/i586/libpostproc0-1.0-0.pre3.14.12.C30mdk.i586.rpm bd302e5db44860753ada86b1229a8d5d corporate/3.0/i586/libpostproc0-devel-1.0-0.pre3.14.12.C30mdk.i586.rpm 828c20f259283b69aadf064c56fad11f corporate/3.0/i586/mencoder-1.0-0.pre3.14.12.C30mdk.i586.rpm cb41721c4bb550af139ac3b8e44d73a6 corporate/3.0/i586/mplayer-1.0-0.pre3.14.12.C30mdk.i586.rpm 0df3b055e8dec142b7041d3e2454688b corporate/3.0/i586/mplayer-gui-1.0-0.pre3.14.12.C30mdk.i586.rpm 15197a8db2b41eb6051e976c5411341a corporate/3.0/SRPMS/mplayer-1.0-0.pre3.14.12.C30mdk.src.rpm Corporate 3.0/X86_64: f74386a58305e0f50cdbecbcd5c3f0b3 corporate/3.0/x86_64/lib64postproc0-1.0-0.pre3.14.12.C30mdk.x86_64.rpm 656b76d2ad1fdd78daaa5bca0a3d014f corporate/3.0/x86_64/lib64postproc0-devel-1.0-0.pre3.14.12.C30mdk.x86_64.rpm de8581bfb537adaac8a0eb47f96fe4bd corporate/3.0/x86_64/mencoder-1.0-0.pre3.14.12.C30mdk.x86_64.rpm 5a4e7cccb601485889ed3619492ec839 corporate/3.0/x86_64/mplayer-1.0-0.pre3.14.12.C30mdk.x86_64.rpm f3ea84ee2e18f7457674daff97646bb1 corporate/3.0/x86_64/mplayer-gui-1.0-0.pre3.14.12.C30mdk.x86_64.rpm 15197a8db2b41eb6051e976c5411341a corporate/3.0/SRPMS/mplayer-1.0-0.pre3.14.12.C30mdk.src.rpm ___ To upgrade automatically use MandrivaUpdate or urpmi. The verification of md5 checksums and GPG signatures is performed automatically for you. All packages are signed by Mandriva for security. You can obtain the GPG public key of the Mandriva Security Team by executing: gpg --recv-keys --keyserver pgp.mit.edu 0x22458A98 You can view other update advisories for Mandriva Linux at: http://www.mandriva.com/security/advisories If you want to report vulnerabilities, please contact security_(at)_mandriva.com
Re: [Full-disclosure] Internet Explorer 0day exploit
Thor Larholm wrote: There is a URL protocol handler command injection vulnerability ... http://larholm.com/2007/07/10/internet-explorer-0day-exploit/ I wonder whether this is essentially different from: Microsoft Internet Explorer 6 Protocol Handler Vulnerability http://www.securityfocus.com/archive/1/370959 http://www.securityfocus.com/archive/1/371061 http://lists.grok.org.uk/pipermail/full-disclosure/2004-August/024833.html Please enlighten. Thanks, Paul Szabo [EMAIL PROTECTED] http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia ___ 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] An Auction Site for Vulnerabilities
I encourage everyone to research and release exploits for every bug on the auction block. Remember: it is only consistent with REAL hacker ethics to sell bugs to terrorists, NAMBLA, and similar organizations such as GOBBLES/n3td3v. J Great job smartass, with your ego driven post you have just achieved 3 important goals: a) the researcher won't be paid b) any script kiddie on the planet can finally have his root shell. c) the world is now a less secure place Thank you! Fussy? Opinionated? Impossible to please? Perfect. Join Yahoo!'s user panel and lay it on us. http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 ___ 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 07.09.07: IBM AIX libodm ODMPATH Stack Overflow Vulnerability
IBM AIX libodm ODMPATH Stack Overflow Vulnerability iDefense Security Advisory 07.09.07 http://labs.idefense.com/intelligence/vulnerabilities/ Jul 09, 2007 I. BACKGROUND AIX applications use libodm to access system settings and device configuration data stored in the Object Database Manager. The Manager is responsible for accessing and updating such things as currently installed software packages and devices. Many of the applications that use libodm are installed set-uid root. II. DESCRIPTION Local exploitation of a buffer overflow vulnerability in IBM Corp.'s AIX libodm library could allow an attacker to execute arbitrary code on a targeted host. The vulnerability exists in the processing of the ODMPATH environment variable within the odm_searchpath() function. This function reads the ODMPATH variable from the user provided environment, and then copies it into a fixed sized stack buffer without properly validating its length. This results in a stack-based buffer overflow, and allows the saved return address to be overwritten. III. ANALYSIS Exploitation allows an attacker to execute code with root privileges. Since this is a local attack, an attacker has complete control over the process environment and can reliably place shellcode at known addresses. This makes exploitation of this vulnerability trivial. IV. DETECTION iDefense has confirmed the existence of this vulnerability in AIX version 5.3 SP 4. Previous versions may be vulnerable. V. WORKAROUND iDefense is currently unaware of any workarounds for this issue. VI. VENDOR RESPONSE IBM Corp. has addressed this vulnerability with interim fixes. More information is available at the following URL. http://www-1.ibm.com/support/docview.wss?uid=isg1IY97632 VII. CVE INFORMATION A Mitre Corp. Common Vulnerabilities and Exposures (CVE) number has not been assigned yet. VIII. DISCLOSURE TIMELINE 04/02/2007 Initial vendor notification 04/05/2007 Initial vendor response 07/09/2007 Coordinated public disclosure IX. CREDIT The discoverer of this vulnerability wishes to remain anonymous. Get paid for vulnerability research http://labs.idefense.com/methodology/vulnerability/vcp.php Free tools, research and upcoming events http://labs.idefense.com/ X. LEGAL NOTICES Copyright © 2007 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 e-mail [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/
[Full-disclosure] Fling it all back home...
Annoyed of Fling popups everywere?
Play with 'em!
1) Go to Fling.com
2) User: [EMAIL PROTECTED]
3) Pwd: scriptalert('I am lame')/script
Cheers.
--
[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] The Auction Site made Forbes.
On Mon, 09 Jul 2007 18:23:49 EDT, [EMAIL PROTECTED] said: There hasn't been a high profile lawsuit against a vuln researcher for finding and selling an 0day at this point (that I can think of) and it's only a matter of time before it happens. Given the number of highly regarded people who have had legal threats against them already (the DMCA actions against Ed Felton, Cisco against Michael Swan, and a number of BlackHat and similar presentations that have been withdrawn after legal threats), It's likely that a matter of time is sooner rather than later, and people should include that in their 0day release planning... pgpDprApXkAdW.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] Google/Orkut Authentication/Session Management Issue PoC - Interim Results
An Orkut session cookie once stolen can be used by an attacker to mess with the compromised account as long as the session associated with that cookie remains alive at the server. Unfortunately, in case of Orkut, it remains alive even after the user has logged out. Joseph's experiment proves that it takes a pretty long time for the session to expire. So, the user of a compromised account has to either wait for the session to expire or hope that Google does something to terminate the sessions of the users who have logged out. Regards, Susam Pal http://susam.in/ Neeraj Agarwal wrote, On Tuesday 10 July 2007 02:44 PM: my firnd got my session cookie a day before yesterdy.. is there any method i can stop him by using my orkut account? On 7/10/07, *Deeþàn Chakravarthÿ* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Joseph Hick wrote: If you sign into orkut.com http://orkut.com then enter orkut in the filter box then you will see some orkut cookies. Look for orkut_state in www.orkut.com http://www.orkut.com site. It will work if you are logged in. if you log out orkut_state cookie disappears but the session remains active in orkut.com http://orkut.com server. So a big problem is happening in orkut. when attackers stole some cookies using XSS attacks earlier they were misusing the accounts after owner of account logged out. This problem is happening because after owner of account logged out the session remained active. In other sites like yahoo this is not possible because the session deactivates in the server after owner of account logs out. Hi Joseph, Thanks, I was looking for the cookie after logging off. Thanks Deepan --- Deeþàn Chakravarthÿ [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: It works great. But I am not able to find a similar cookie for my account. Am I missing something ? Thanks Deepan Joseph Hick wrote: This is the interim result of a proof of concept for Google Authentication issues posted in the threads... 1.) http://lists.grok.org.uk/pipermail/full-disclosure/2007-June/064143.html http://lists.grok.org.uk/pipermail/full-disclosure/2007-June/064143.html (Orkut Server Side Management Error by Susam Pal Vipul Agarwal) 2.) http://lists.grok.org.uk/pipermail/full-disclosure/2007-June/064300.html (Google Re-authentication Bypass by Susam Pal) A session was created in Orkut at about Sat Jun 30 20:30 UTC 2007. Between June 30 and now many have hijacked this session and logged out many times but the session is alive today as verified on Sun Jul 8 at 09:43:10 UTC 2007. ___ 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] Announce: RFIDIOt PC/SC support - new release 0.1p (July 2007)
Folks, I'm pleased to announce that I've finally got around to releasing PC/SC support for RFIDIOt. This means you can use lower cost reader/writers that are also much easier to find (although at the moment there are limitations as to what you can do with them, so they are not a complete alternative). So far I've only tested the Omnikey Cardman 5321, which is a 13.56MHz device, and am able to access things like e-passports, Mifare cards and ISO 15693 (commonly used in ticketing and hotel doors etc.). No doubt there are some simple tweaks that would enable more of the other test programs to work but I felt there was enough here to get people started so didn't want to delay the release any further... Full list of changes in this release: v0.p add PCSC support (http://pcsclite.alioth.debian.org/ and http://pyscard.sourceforge.net/) [hints/tips/inspiration Henryk Plötz] fix cardselect.py and multiselect.py to check for presence of card fix 'waitfor/do nothing' in RFIDIOt.py [Philippe Biondi] cleaner check digit calc in mrpkey.py [Philippe Biondi] change -r to -R (reader type) to allow -r to be used for PCSC compatibility add speed/framesize reporting to mrpkey.py increase MAX read chunk size to 118 in mrpkey.py (needs fixing to go up to device supported size ISO_FRAMESIZE) fix bit allignment issue in FDXBID encoding/decoding [Matsche] add global uid variable add locked block reporting to readmifare add readmifaresimple.py Full details here: http://rfidiot.org enjoy, Adam -- Adam Laurie Tel: +44 (0) 1304 814800 The Bunker Secure Hosting Ltd. Fax: +44 (0) 1304 814899 Ash Radar Station Marshborough Road Sandwichmailto:[EMAIL PROTECTED] Kent CT13 0PL UNITED KINGDOM PGP key on keyservers ___ 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] Internet Explorer 0day exploit
On Tue, 10 Jul 2007, Thor Larholm wrote: There is a URL protocol handler command injection vulnerability in Internet Thor, thank you for sharing. Nice work. To paraphrase Guninski, this is still not a 0day. It is a vulnerability being disclosed. Explorer for Windows that allows you to execute shell commands with arbitrary arguments. This vulnerability can be triggered without user interaction simply by visiting a webpage. When Internet Explorer encounters a reference to content inside a registered URL protocol handler scheme it calls ShellExecute with the EXE image path and passes the entire request URI without any input validation. For the sake of demonstration I have constructed an exploit that bounces through Firefox via the FirefoxURL protocol handler. The full advisory and a working Proof of Concept exploit can be found at http://larholm.com/2007/07/10/internet-explorer-0day-exploit/ Cheers Thor Larholm ___ 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] [ MDKSA-2007:144 ] - Updated OpenOffice.org packages fix RTF import vulnerability
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ___ Mandriva Linux Security Advisory MDKSA-2007:144 http://www.mandriva.com/security/ ___ Package : openoffice.org Date: July 10, 2007 Affected: 2007.0, 2007.1, Corporate 3.0 ___ Problem Description: A heap overflow flaw was found in the RTF import filter of OpenOffice.org. If a victim were to open a specially-crafted RTF file, OpenOffice.org could crash or possibly execute arbitrary code. Updated packages have been patched to prevent the above issues. ___ References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0245 ___ Updated Packages: Mandriva Linux 2007.0: 91bf0ba573f2c60366d5e9d20ac7a7b6 2007.0/i586/openoffice.org-2.0.4-2.5mdv2007.0.i586.rpm 16452b7778ca0f34518dbea0dc825806 2007.0/i586/openoffice.org-devel-2.0.4-2.5mdv2007.0.i586.rpm 4a750a73b6cb19d9e804051b27f59780 2007.0/i586/openoffice.org-devel-doc-2.0.4-2.5mdv2007.0.i586.rpm 978d48633bea89a4d96100b6627dcb3e 2007.0/i586/openoffice.org-galleries-2.0.4-2.5mdv2007.0.i586.rpm 028e143a6184be8893bf2cd125fef385 2007.0/i586/openoffice.org-gnome-2.0.4-2.5mdv2007.0.i586.rpm e732093fbd1860202c358ab804e05083 2007.0/i586/openoffice.org-kde-2.0.4-2.5mdv2007.0.i586.rpm f2e672878d2360c2b740fa47864c6b2c 2007.0/i586/openoffice.org-l10n-af-2.0.4-2.5mdv2007.0.i586.rpm cf6f70615f27d88909bfd34dcf34c163 2007.0/i586/openoffice.org-l10n-ar-2.0.4-2.5mdv2007.0.i586.rpm 1bb6b86c0805b0f4762298719def29e0 2007.0/i586/openoffice.org-l10n-bg-2.0.4-2.5mdv2007.0.i586.rpm 2dfd6acd7d8ccdb1c2cbfac38cf67fe7 2007.0/i586/openoffice.org-l10n-br-2.0.4-2.5mdv2007.0.i586.rpm 97d7ae10d7858915a59ec87bf37c9a00 2007.0/i586/openoffice.org-l10n-bs-2.0.4-2.5mdv2007.0.i586.rpm 26c8484fbd05b498588d9f9714222613 2007.0/i586/openoffice.org-l10n-ca-2.0.4-2.5mdv2007.0.i586.rpm d5f04dfe7d4fdffc27a95e97bb059968 2007.0/i586/openoffice.org-l10n-cs-2.0.4-2.5mdv2007.0.i586.rpm d3d88df4a0ad3c84d5e719c426c586cf 2007.0/i586/openoffice.org-l10n-cy-2.0.4-2.5mdv2007.0.i586.rpm a3ed0f3e625b6576c97c2d7950e6e83a 2007.0/i586/openoffice.org-l10n-da-2.0.4-2.5mdv2007.0.i586.rpm eccfd3df4fe18aecd82b7f00eca48b85 2007.0/i586/openoffice.org-l10n-de-2.0.4-2.5mdv2007.0.i586.rpm 602e9465ad5b2b71c09da0bf9589c837 2007.0/i586/openoffice.org-l10n-el-2.0.4-2.5mdv2007.0.i586.rpm dff0977565cfca8c69664da22660e19c 2007.0/i586/openoffice.org-l10n-en_GB-2.0.4-2.5mdv2007.0.i586.rpm 429db2d76d47420e1a268ec375d6ba3c 2007.0/i586/openoffice.org-l10n-es-2.0.4-2.5mdv2007.0.i586.rpm 3a6bb5940eac7d916ffafc94da255ff2 2007.0/i586/openoffice.org-l10n-et-2.0.4-2.5mdv2007.0.i586.rpm d05514e60a8e5ee9511915e2ce4c7906 2007.0/i586/openoffice.org-l10n-eu-2.0.4-2.5mdv2007.0.i586.rpm 3445a11e611970a4f46b918a3b6fe053 2007.0/i586/openoffice.org-l10n-fi-2.0.4-2.5mdv2007.0.i586.rpm 6cd6faadd3c3529c0acbd083d56d936c 2007.0/i586/openoffice.org-l10n-fr-2.0.4-2.5mdv2007.0.i586.rpm fbe2433958e475570b3c97110d1fd724 2007.0/i586/openoffice.org-l10n-he-2.0.4-2.5mdv2007.0.i586.rpm aee9471fd5af25b04df70e3e0384082b 2007.0/i586/openoffice.org-l10n-hi-2.0.4-2.5mdv2007.0.i586.rpm ae8646ce6bfeb2da8b2a7377f06f2ea3 2007.0/i586/openoffice.org-l10n-hu-2.0.4-2.5mdv2007.0.i586.rpm c6dc22808a51b7eb611b4b666566bf00 2007.0/i586/openoffice.org-l10n-it-2.0.4-2.5mdv2007.0.i586.rpm ae40cd8d31624a1f40c1e2f555ef5fd2 2007.0/i586/openoffice.org-l10n-ja-2.0.4-2.5mdv2007.0.i586.rpm d451bd7561e361774ed68ffab2faa13f 2007.0/i586/openoffice.org-l10n-ko-2.0.4-2.5mdv2007.0.i586.rpm 5e7137e80891b55954ba56ffcd558e47 2007.0/i586/openoffice.org-l10n-mk-2.0.4-2.5mdv2007.0.i586.rpm c64ed8f9bb1510e35f20196e39f6c99a 2007.0/i586/openoffice.org-l10n-nb-2.0.4-2.5mdv2007.0.i586.rpm 3924ce8a8419c63c35e5e33cada62479 2007.0/i586/openoffice.org-l10n-nl-2.0.4-2.5mdv2007.0.i586.rpm b9c1c52327a60dd95d0487acd9b7b340 2007.0/i586/openoffice.org-l10n-nn-2.0.4-2.5mdv2007.0.i586.rpm c8b27099495fe22ef8af3d64856eacfe 2007.0/i586/openoffice.org-l10n-pl-2.0.4-2.5mdv2007.0.i586.rpm d32e8607d6ebf3ad635ca89224cae387 2007.0/i586/openoffice.org-l10n-pt-2.0.4-2.5mdv2007.0.i586.rpm fa61997058897952f9a0610a93bb5ed3 2007.0/i586/openoffice.org-l10n-pt_BR-2.0.4-2.5mdv2007.0.i586.rpm 18205cf72d602ca0510b25d767c2eef3 2007.0/i586/openoffice.org-l10n-ru-2.0.4-2.5mdv2007.0.i586.rpm f40966cb87c765b0f3d8a28e3d472077 2007.0/i586/openoffice.org-l10n-sk-2.0.4-2.5mdv2007.0.i586.rpm 56be57fc3cb2c11eb542bf966164a99d 2007.0/i586/openoffice.org-l10n-sl-2.0.4-2.5mdv2007.0.i586.rpm 178fa38d963bf8a3a49bdd4456951d7e 2007.0/i586/openoffice.org-l10n-sv-2.0.4-2.5mdv2007.0.i586.rpm
[Full-disclosure] [GOODFELLAS - VULN] sasatl.dll 1.5.0.531 Program Checker - Javascript Heap Spraying Exploit
Sorry guys, we apologize for sending this again, but some of the mailer daemons are responding us that the mail has a virus. Here is the link to the bug: http://goodfellas.shellcode.com.ar/own/VULWAR200707101.txt Goodfellas SRT. ___ 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] EEYE: Microsoft Publisher 2007 Arbitrary Pointer Dereference
Microsoft Publisher 2007 Arbitrary Pointer Dereference
Release Date:
July 10, 2007
Date Reported:
February 16, 2007
Severity:
High (Remote Code Execution)
Vendor:
Microsoft
Vendor Software Affected:
Microsoft Office 2007 Small Business
Microsoft Office 2007 Professional
Microsoft Office 2007 Ultimate
Microsoft Office 2007 Professional Plus
Microsoft Office 2007 Enterprise
Microsoft Publisher 2007 Standalone
Operating Systems Affected:
Windows XP (All versions)
Windows 2003 (All versions)
Windows Vista (All versions)
Overview:
eEye Digital Security has discovered a critical vulnerability in PUBCONV.DLL
(version 12.0.4518.1014) included with Microsoft's Publisher 2007. PUBCONV.DLL
is the Publisher conversion library used by Publisher to translate previous
Publisher version files to be properly rendered in Publisher 2007. However,
when attempting to load a malformed legacy Publisher document (i.e. Publisher
98), PUBCONV.DLL can be forced to call an arbitrary function pointer resulting
in the execution of attacker supplied code in the context the of logged-in user.
Technical Details:
The vulnerability affecting Publisher 2007 is a two stage pointer overwrite
within the functions of '3452EC8C' and '34530514' within PUBCONV.DLL. Prior to
the exploitable sections of code, function '34542916' in PUBCONV.DLL copies a
1Eh-byte record from a legacy Publisher 98 file's textbox object and then
inserts it into a stack variable. Only files saved in the Publisher 98 legacy
format that contain an embedded textbox object are vulnerable to the exploit.
The structure of the loaded data is as follows:
+00h WORD number of entries (0016h)
+02h WORD same? (0016h)
+04h WORD size of each entry (001Eh)
+06h [0Ch] {0}
+12h int[] array of 'number of entries' integers
gets binary searched by sub_345309CE
to convert int to index
x+00h DWORD ??? (7F66h)
x+04h int[] array of 'number of entries'
structures, of size 'size of each entry'
+00h DWORD ** Sanitization Check Integer (EEh)
+04h DWORD index of entry? (1..16h)
+08h PTR ** Arbitrary Pointer (41414141h) **
+0Ch PTR ** Arbitrary Pointer (42424242h) **
A hex dump of the vulnerable area inside the malicious file is below:
f130h: 00 16 16 1E 00 01 66 66 66 7F 01 EE EE EE EE EE;
...`..fff¬.î
f140h: EE EE EE 00 00 00 01 41 41 41 41 42 42 42 42 00;
îîî.
After function '34542916' copies the data structure into memory, normally the
double set of pointers at 0x08h and 0x0Ch are sanitized to NULL values in
memory by the function '3452EC8C'. The sanitization function '3452EC8C' loads
the value of the sanitization check integer into ESI, and compares it to zero.
If this value is a negative value (as seen above with the value
0x), it mistakenly jumps over the sanitization procedure and
continues loading the malformed data structure.
3452ECB0 cmp dword ptr [esi], 0 ; Compare sanitization check
; Integer to 0
3452ECB3 jl short loc_3452ECD3 ; If negative, exit loop, this
; Allows arbitrary
pointers
; To be called.
3452ECC3 lea eax, [esi+0Ch] ; Move EAX to 0x0C
3452ECC6 and dword ptr [eax-4], 0 ; Sanitizes pointer at 0x08
; to NULL
3452ECCA and dword ptr [eax], 0 ; Sanitizes 2nd pointer at
; 0x0C to NULL
3452ECCD add eax, 1Eh ; 1Eh = size of entries
3452ECD0 dec edi; EDI = Number of
entries
3452ECD1 jnz short loc_3452ECC6 ; Loop thru all entries
Once the sanitization procedure inside function '3452EC8C' has been bypassed
with a negative value, the 2nd stage of the vulnerability takes place inside
function '32530514'. The function '34530514' dereferences the arbitrary pointer
(stored in [EBP+var_1C] in the disassembly below) to read another
attacker-controlled pointer, which is treated as the address of a table of
function pointers. The vulnerable pointer then can be used to reference the
payload stored inside the malicious Publisher file and redirect code execution
towards the attacker-controlled payload, resulting in arbitrary code execution
in the context of the logged in user. Below is the disassembly of the
vulnerable function '34530514' inside PUBCONV.DLL (version 12.0.4518.1014)
sub_34530514
...
345305B9 mov eax, [ebp+var_1C] ; Arbitrary Pointer at 0x08h
; Is stored in EAX
...
345305C8 mov ecx, [eax] ; ECX now loads the arbitrary
Re: [Full-disclosure] Wachovia Bank website sends confidential information
On Tue, 2007-07-10 at 20:20 -0400, Bob Toxen wrote: VI. VENDOR RESPONSE The vendor (Wachovia Bank) was notified via their customer service phone number on June 25. We were transferred to web support. The person answering asked us to FAX the details to her and we did so, also on June 25. We explained that we were reporting a severe security problem on their web site. Severe? All that seems to be leaked is a person's Name/Address/SSN number and some other details. While this is too much info to leak, I'd hardly say it's severe. That same info can be easily found in people's mailboxes weekdays between noon and 4pm. We stated that that if we did not hear back from them within 7 days and the problem was not fixed by then that we would post the problem on the Full Disclosure list, following accepted industry practice. 7 days? industry practice? Come on Bob I know you know that large corporations can't feed a cat in 7 days let alone make unscheduled website changes that fast. Change control approvals alone would include 14 or more days in most enterprises. Why the rush to say so? -Jim P. ___ 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] Wachovia Bank website sends confidential information
On 10-Jul-07, at 7:39 PM, Jim Popovitch wrote: On Tue, 2007-07-10 at 20:20 -0400, Bob Toxen wrote: VI. VENDOR RESPONSE The vendor (Wachovia Bank) was notified via their customer service phone number on June 25. We were transferred to web support. The person answering asked us to FAX the details to her and we did so, also on June 25. We explained that we were reporting a severe security problem on their web site. Severe? All that seems to be leaked is a person's Name/Address/SSN number and some other details. While this is too much info to leak, I'd hardly say it's severe. That same info can be easily found in people's mailboxes weekdays between noon and 4pm. Yeah, but that doesn't scale as well. --- Tremaine Lea Network Security Consultant Intrepid ACL Paranoia for hire ___ 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] Wachovia Bank website sends confidential information
On Tue, 10 Jul 2007 21:39:33 EDT, Jim Popovitch said: 7 days? industry practice? Come on Bob I know you know that large corporations can't feed a cat in 7 days let alone make unscheduled website changes that fast. Change control approvals alone would include 14 or more days in most enterprises. Why the rush to say so? On the other hand, I think that they *could* manage at least a Wow d00dz, we really *do* have a hole there reply and at least give a handwaving about when they'd fix it. Of course, actually *fixing* a design flaw that big is going to take them *months*. pgpmZBnZhDZmO.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] [ MDKSA-2007:145 ] - Updated wireshark packages fix multiple vulnerabilities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ___ Mandriva Linux Security Advisory MDKSA-2007:145 http://www.mandriva.com/security/ ___ Package : wireshark Date: July 10, 2007 Affected: 2007.0, 2007.1, Corporate 4.0 ___ Problem Description: A number of vulnerabilities in the Wireshark program were found that could cause crashes, excessive looping, or exhaustion of system memory. This updated provides wireshark 0.99.6 which is not vulnerable to these issues. ___ References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3389 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3390 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3391 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3392 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3393 http://www.wireshark.org/security/wnpa-sec-2007-02.html ___ Updated Packages: Mandriva Linux 2007.0: b033f6eadc258c248d9fba4469b838e1 2007.0/i586/libwireshark0-0.99.6-0.1mdv2007.0.i586.rpm 5aad6a1e489f750ddf174649a6319ca2 2007.0/i586/tshark-0.99.6-0.1mdv2007.0.i586.rpm c394ef661021c5e62bed70c21c315ffd 2007.0/i586/wireshark-0.99.6-0.1mdv2007.0.i586.rpm e851b58c639407a7c9ae25fcfd336774 2007.0/i586/wireshark-tools-0.99.6-0.1mdv2007.0.i586.rpm 72beadc31f718f860324544019d3adc3 2007.0/SRPMS/wireshark-0.99.6-0.1mdv2007.0.src.rpm Mandriva Linux 2007.0/X86_64: dd9d7af8d82a2eacc871e6a919cad3af 2007.0/x86_64/lib64wireshark0-0.99.6-0.1mdv2007.0.x86_64.rpm 452de6307f10772c68ebae473ae3c537 2007.0/x86_64/tshark-0.99.6-0.1mdv2007.0.x86_64.rpm fa4cc3d56186068a13549dc754529198 2007.0/x86_64/wireshark-0.99.6-0.1mdv2007.0.x86_64.rpm 74dab97371727e367e997a1a90f7263b 2007.0/x86_64/wireshark-tools-0.99.6-0.1mdv2007.0.x86_64.rpm 72beadc31f718f860324544019d3adc3 2007.0/SRPMS/wireshark-0.99.6-0.1mdv2007.0.src.rpm Mandriva Linux 2007.1: a5b8f29cdc32543659a8e0c23f146e33 2007.1/i586/libwireshark0-0.99.6-0mdv2007.1.i586.rpm ceb71b951f1185741c9b9be50fda7acc 2007.1/i586/tshark-0.99.6-0mdv2007.1.i586.rpm 188ee566b140d3a5a270106fdba86516 2007.1/i586/wireshark-0.99.6-0mdv2007.1.i586.rpm 4a4e07651e01dd9177548b37b7888971 2007.1/i586/wireshark-tools-0.99.6-0mdv2007.1.i586.rpm 9ab979db8a493c6d35ee621667af6806 2007.1/SRPMS/wireshark-0.99.6-0mdv2007.1.src.rpm Mandriva Linux 2007.1/X86_64: 83ca8b3c25af33fd0f53ac2bff0adc21 2007.1/x86_64/lib64wireshark0-0.99.6-0mdv2007.1.x86_64.rpm 4f8159feba8f9cd498d9d6e810a0e555 2007.1/x86_64/tshark-0.99.6-0mdv2007.1.x86_64.rpm 6cf73daa791ecbcacb505016e0050823 2007.1/x86_64/wireshark-0.99.6-0mdv2007.1.x86_64.rpm fa1e1783c619d908a5d0b260adbb5c9f 2007.1/x86_64/wireshark-tools-0.99.6-0mdv2007.1.x86_64.rpm 9ab979db8a493c6d35ee621667af6806 2007.1/SRPMS/wireshark-0.99.6-0mdv2007.1.src.rpm Corporate 4.0: e0bd9a03651d4f29034088368b81aab8 corporate/4.0/i586/libwireshark0-0.99.6-0.1.20060mlcs4.i586.rpm 1bbb1205a0f0a2d0107f1a6992ceae83 corporate/4.0/i586/tshark-0.99.6-0.1.20060mlcs4.i586.rpm 88828ce0dc609d86ff1987464813fa02 corporate/4.0/i586/wireshark-0.99.6-0.1.20060mlcs4.i586.rpm b1180bb4471aabf35620e391475f81ff corporate/4.0/i586/wireshark-tools-0.99.6-0.1.20060mlcs4.i586.rpm b72cf2010d3c7afd8f00e99ed6d28430 corporate/4.0/SRPMS/wireshark-0.99.6-0.1.20060mlcs4.src.rpm Corporate 4.0/X86_64: 794ca2e7faf95f0c6f6527523bbd56cb corporate/4.0/x86_64/lib64wireshark0-0.99.6-0.1.20060mlcs4.x86_64.rpm 4673373f4d25fafb8da9b306c7afc0c6 corporate/4.0/x86_64/tshark-0.99.6-0.1.20060mlcs4.x86_64.rpm 8a1d126e0524d69fb719c9374f45d64d corporate/4.0/x86_64/wireshark-0.99.6-0.1.20060mlcs4.x86_64.rpm 5d86ebcdf606a1c8406ddb6a086c09e6 corporate/4.0/x86_64/wireshark-tools-0.99.6-0.1.20060mlcs4.x86_64.rpm b72cf2010d3c7afd8f00e99ed6d28430 corporate/4.0/SRPMS/wireshark-0.99.6-0.1.20060mlcs4.src.rpm ___ To upgrade automatically use MandrivaUpdate or urpmi. The verification of md5 checksums and GPG signatures is performed automatically for you. All packages are signed by Mandriva for security. You can obtain the GPG public key of the Mandriva Security Team by executing: gpg --recv-keys --keyserver pgp.mit.edu 0x22458A98 You can view other update advisories for Mandriva Linux at: http://www.mandriva.com/security/advisories If you want to report vulnerabilities, please contact security_(at)_mandriva.com ___ Type Bits/KeyID Date User ID pub 1024D/22458A98 2000-07-10 Mandriva Security Team security*mandriva.com
