Re: [Full-Disclosure] Insecurity in Finnish parlament (computers)
I will contact all the base station vendors, as I want to be sure about this. Your answer below is in fact what I expected - you can not be sure about this issue, because you can not proof it. Regards, Olli On 2/23/06, Markus Jansson <[EMAIL PROTECTED]> wrote: > Olli Haukkovaara sayed: > >Can you state some models of GSM base stations > >/,"message centers" that support A5/3 in GSM > >networks? > > No, I cant, because Im not an expert on GSM base station hardware > systems. :) I bet you better ask Nokia & Elisa about that issue (and > hope that they will answer you anything)...unless someone in the list > can point out references? I only know that there is hardware for that > and it is used. I cant name the brand and model of it. ;) > > > -- > My computer security & privacy related homepage > http://www.markusjansson.net > Use HushTools or GnuPG/PGP to encrypt any email > before sending it to me to protect our privacy. > -- terveisin, Olli ___ 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] Detours and Trojans
It's not the first time that malwares are using detours techniques. In case your malware is "Trojan.Anserin" (http://securityresponse.symantec.com/avcenter/venc/data/trojan.anserin.html) It tries to hooks several APIs of the common browsers for keylogging/password stealing purposes (IEXPLORE, FIREFOX, MOZILLA, OPERA). It tries to steal bank accounts and other confindential information. Some variants try also to patch NSPR4.DLL (Netscape lib) altering the following functions: PR_Connect(), PR_Read(), PR_Write(), PR_Close() EF - Original Message - From: Tiago Halm [mailto:[EMAIL PROTECTED] To: full-disclosure@lists.grok.org.uk Sent: Wed, 22 Feb 2006 22:47:40 +0100 Subject: [Full-disclosure] Detours and Trojans > Detours is being used on trojans. > Just got one *sighs* and detours was making sure the processes could not be > killed. > > the files were: > c:\Program Files\Common Files\Microsoft Shared\Web Folders\ibm2.dll > (around 48k) > c:\Program Files\Common Files\Microsoft Shared\Web Folders\ibm3.dll > (around 48k) > c:\Program Files\Common Files\Microsoft Shared\Web Folders\ibm3.exe --> > this file was 2k > c:\Program Files\Common Files\Microsoft Shared\Web Folders\ibm4.dll > (around 48k) > > current user "Run" was mapped to ibm3.exe above. > > Unfortunatelly I deleted the files (in case anyone was interested), because > google did not show much info on this and I didn't know much more of what to > do. > did some strings on the files above and showed http posts (uploads) of some > local files. > sorry I don't have any more information. don't remember. > > anyone saw this already? > > Tiago Halm > ___ > 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] fun w/phishers?
The weird part is that site is hosted on Egyptian Universities Network! Was this a research project sponsored by university? http://193.227.1.9/docs-n/index-ee.php On 2/23/06, Orlando Padilla <[EMAIL PROTECTED]> wrote: http://193.227.1.9/heep2/templates/.ssl/CERTIFICATEID-535GDW98/SECUREDSITE/www/paypal.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 - 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 Contact at Network Intelligence?
Hi All, Anyone got any contacts at Network Intelligence? I can't find shit on their site at all :-( I'm going to call them when they wake up later on as a worst case. TIA xyberpix ___ 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] Firewall bug or not ?
Hi, I have problem with connections through Cisco PIX ( ver. 6.3 ) During connection to Web site, suddenly after choosing next page on one form the connection was broken. ( WEB with aspx and _javascript_ ) Using traffic to this Web site through Checkpoint it works. Tested from different sites where I suppose were not PIX and it has worked ! Is it bug on PIX or Checkpoint ? --- In my log on PIX : Feb 23 07:28:41 PIX-ADR %PIX-6-302013: Built outbound TCP connection 417324 304 for outside: OUT-WEB-SERV /80 (OUT-WEB-SERV/80) to inside: LOCAL-PC/1154 (STATIC-IP-ON-PIX/1154) Feb 23 07:28:41 PIX-ADR %PIX-5-304001: LOCAL-PC Accessed URL OUT-WEB-SERV:/images/px.gif Feb 23 07:28:42 PIX-ADR %PIX-6-302014: Teardown TCP connection 417324304 fo r outside: OUT-WEB-SERV/80 to inside: LOCAL-PC /1154 duration 0:00:01 bytes 52 93 TCP Reset-I Feb 23 07:28:42 PIX-ADR %PIX-6-106015: Deny TCP (no connection) from LOCAL-PC/1154 to OUT-WEB-SERW /80 flags RST on interface inside Feb 23 07:28:42 PIX-ADR %PIX-6-106015: Deny TCP (no connection) from LOCAL-PC /1154 to OUT-WEB-SERW /80 flags RST on interface inside Feb 23 07:28:42 PIX-ADR %PIX-6-302014: Teardown TCP connection 417324262 fo r outside: OUT-WEB-SERV/80 to inside: LOCAL-PC /1153 duration 0:00:01 bytes 45 634 TCP FINs It looks like this WEB application send packet with RST against FIN and then try to resend traffic to my PC but PIX doesn’t allow to connect treated RST as just reset connection. Why for example Checkpoint allow to keep this connection ? Any bug ? Thanks in advance ! Regards, Michal Grzybczyk ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Secunia Research: Visnetic AntiVirus Plug-in for MailServer Privilege Escalation
== Secunia Research 23/02/2006 - Visnetic AntiVirus Plug-in for MailServer Privilege Escalation - == Table of Contents Affected Software1 Severity.2 Vendor's Description of Software.3 Description of Vulnerability.4 Solution.5 Time Table...6 Credits..7 References...8 About Secunia9 Verification10 == 1) Affected Software Visnetic AntiVirus Plug-in for MailServer 4.6.0.4 and 4.6.1.1. NOTE: Other versions may also be affected. == 2) Severity Rating: Less critical Impact: Privilege escalation Where: Local system == 3) Vendor's Description of Software "The best means of protecting your organization from email-propagated viruses is antivirus protection for your mail server. The VisNetic AntiVirus Plug-in is tightly integrated antivirus protection designed specifically for VisNetic Mail Server.". Product Link: http://www.deerfield.com/products/visnetic-mailserver/antivirus/ == 4) Description of Vulnerability Secunia Research has discovered a vulnerability in Visnetic AntiVirus Plug-in for MailServer, which can be exploited by malicious, local users to gain escalated privileges. The vulnerability is caused due to the Visnetic AntiVirus Plug-in (DKAVUpSch.exe) not dropping its privileges before invoking other programs. This can be exploited to invoke arbitrary programs on the system with SYSTEM privileges. == 5) Solution Update to version 4.6.1.2. == 6) Time Table 07/09/2005 - Vendor notified (1st notice). 07/02/2006 - Vendor notified (2nd notice). 21/02/2006 - Vendor notified (3rd notice). 21/02/2006 - Vendor response. 23/02/2006 - Public disclosure. == 7) Credits Discovered by Secunia Research. == 8) References The Common Vulnerabilities and Exposures (CVE) project has assigned CVE-2006-0812 for the vulnerability. == 9) About Secunia Secunia collects, validates, assesses, and writes advisories regarding all the latest software vulnerabilities disclosed to the public. These advisories are gathered in a publicly available database at the Secunia website: http://secunia.com/ Secunia offers services to our customers enabling them to receive all relevant vulnerability information to their specific system configuration. Secunia offers a FREE mailing list called Secunia Security Advisories: http://secunia.com/secunia_security_advisories/ == 10) Verification Please verify this advisory by visiting the Secunia website: http://secunia.com/secunia_research/2005-65/ Complete list of vulnerability reports published by Secunia Research: http://secunia.com/secunia_research/ == ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Security Contact at Network Intelligence?
[EMAIL PROTECTED] - Isn't that one working for you??? On 2/23/06, Xyberpix <[EMAIL PROTECTED]> wrote: Hi All,Anyone got any contacts at Network Intelligence?I can't find shit on their site at all :-( I'm going to call them when they wake up later on as a worst case.TIAxyberpix___Full-Disclosure - We believe in it.Charter: http://lists.grok.org.uk/full-disclosure-charter.htmlHosted and sponsored by Secunia - http://secunia.com/-- http://www.h4cky0u.org(In)Security at its best... ___ 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] Security Contact at Network Intelligence?
On 2/23/06, Xyberpix <[EMAIL PROTECTED]> wrote: Anyone got any contacts at Network Intelligence?It appears to be [EMAIL PROTECTED]. http://osvdb.org/vendor_dict.php?section=vendor&id=2524&c=N -- http://www.cirt.net | http://www.osvdb.org/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Security Contact at Network Intelligence?
Thanks Sullo, Much appreciated. xyberpix On Thu Feb 23 12:27 , Sullo <[EMAIL PROTECTED]> sent: > >On 2/23/06, Xyberpix <[EMAIL PROTECTED]> wrote: > >Anyone got any contacts at Network Intelligence? > > >It appears to be [EMAIL PROTECTED] > > > >http://osvdb.org/vendor_dict.php?section=vendor&id=2524&c=N > > >-- > >http://www.cirt.net | http://www.osvdb.org/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
RE: [Full-disclosure] Google Reader "preview" and "lens" scriptimproper feed val
hey, nice. Thanks ! :) Good that you have brought up this issue. With the increase in popularity for RSS, it is going to be the target for future bot and worm attacks. RSS feed hijacking will soon become commonplace for worm to easily enter user systems through RSS feeds or news aggregators.. Worst case scenarios in today's RSS is someone post's a link to a malicious website in their RSS feed. This website then takes advantage of browser flaws to infect the user system. nice work Cedric -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Debasis Mohanty Sent: Wednesday, February 22, 2006 11:30 PM To: full-disclosure@lists.grok.org.uk Subject: [Full-disclosure] Google Reader "preview" and "lens" scriptimproper feed validation Google Reader "preview" and "lens" script improper feed validation === I. DESCRIPTION Google Reader (http://www.google.com/reader/) helps organise the contents of those rss or atom feeds for which the user is interested in or subscribed to. The user instead of continuously checking his/her favorite sites or discussion groups for updates, (s)he can let Google Reader do it for them. From news sites to your friends' blogs, Google Reader helps stay up-to-date with all the online information that matters most to the user. II. VULNERABILITY DETAILS Google reader is supposed to display only those contents which the user has subscribed to however two vulnerabilities has been identified which may allow an attacker to entice it's victim (using google reader service) to view unwanted web contents carrying malicious payloads. a. Google reader "preview" script improper feed validation (without user authentication) Google feed reader "preview" script: The script (http://www.google.com/reader/preview/*/feed/) is normally used for displaying the feed contents within the reader. For example, the following request will display the rss content of the link http://www.microsoft.com/athome/security/rss/rssfeed.aspx: http://www.google.com/reader/preview/*/feed/http://www.microsoft.com/athome/ security/rss/rssfeed.aspx Note: '*' in the above link can be replace with any word of your choice otherwise it can be left as it is. This 'preview' script is only available to authenticated user but if a direct link is provided it doens't ask for user authentication. It can be very usefull for an attacker to mount an attack on its victim by directing them to view the content of malicious sites (carrying evil payloads). b. Google reader "lens" script improper feed validation (with user authentication) -- Google feed reader "lens" script: The script (http://www.google.com/reader/lens/feed/) is normally used for displaying contents of only those feeds to which an authenticated user has subscribed to. However, it is possible to pass any rss / atom feed to the script as parameter to which the user has not subscribed but the un-subscribed feed contents can still be loaded within the user reader page. For example, the following request will display the rss content of the link http://www.securityfocus.com/rss/news.xml: http://www.google.com/reader/lens/feed/http://www.securityfocus.com/rss/news .xml This 'lens' script is only available to authenticated user and can be usefull for an attacker to mount an attack on its victim by directing them to view the content of malicious sites (carrying evil payloads) even though the user is not subscribed to. III. VENDOR Google.com IV. HISTORY 30th Jan, 2006 -Bug originally discovered 2nd Feb, 2006 - Vendor Notified ... ... No vendor response ... ... 22nd Feb, 2006 -Vendor Notified again 22nd Feb, 2006 -Public Disclosre IV. CREDITS Debasis Mohanty www.hackingspirits.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/ _ Is your PC infected? Get a FREE online computer virus scan from McAfee® Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 ___ 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] [USN-257-1] tar vulnerability
=== Ubuntu Security Notice USN-257-1 February 23, 2006 tar vulnerability CVE-2006-0300 === A security issue affects the following Ubuntu releases: Ubuntu 5.04 (Hoary Hedgehog) Ubuntu 5.10 (Breezy Badger) The following packages are affected: tar The problem can be corrected by upgrading the affected package to version 1.14-2ubuntu0.1 (for Ubuntu 5.04), or 1.15.1-2ubuntu0.1 (for Ubuntu 5.10). In general, a standard system upgrade is sufficient to effect the necessary changes. Details follow: Jim Meyering discovered that tar did not properly verify the validity of certain header fields in a GNU tar archive. By tricking an user into processing a specially crafted tar archive, this could be exploited to execute arbitrary code with the privileges of the user. The tar version in Ubuntu 4.10 is not affected by this vulnerability. Updated packages for Ubuntu 5.04: Source archives: http://security.ubuntu.com/ubuntu/pool/main/t/tar/tar_1.14-2ubuntu0.1.diff.gz Size/MD5:21395 1f8f561b862e0eaa1d3d76ab5b0805cc http://security.ubuntu.com/ubuntu/pool/main/t/tar/tar_1.14-2ubuntu0.1.dsc Size/MD5: 568 1ac96d117355d0c6501bcfc0603d7f35 http://security.ubuntu.com/ubuntu/pool/main/t/tar/tar_1.14.orig.tar.gz Size/MD5: 1485633 3094544702b1affa32d969f0b6459663 amd64 architecture (Athlon64, Opteron, EM64T Xeon) http://security.ubuntu.com/ubuntu/pool/main/t/tar/tar_1.14-2ubuntu0.1_amd64.deb Size/MD5: 374144 92a29882b472aae37c4f241a2b3d70b7 i386 architecture (x86 compatible Intel/AMD) http://security.ubuntu.com/ubuntu/pool/main/t/tar/tar_1.14-2ubuntu0.1_i386.deb Size/MD5: 366426 bd8a627f95eea1d4dd38da1b8cb755a2 powerpc architecture (Apple Macintosh G3/G4/G5) http://security.ubuntu.com/ubuntu/pool/main/t/tar/tar_1.14-2ubuntu0.1_powerpc.deb Size/MD5: 377108 8d1b6600f06a051dc7236e8e65c2032f Updated packages for Ubuntu 5.10: Source archives: http://security.ubuntu.com/ubuntu/pool/main/t/tar/tar_1.15.1-2ubuntu0.1.diff.gz Size/MD5:28928 e545480fd691241448cd885504e50393 http://security.ubuntu.com/ubuntu/pool/main/t/tar/tar_1.15.1-2ubuntu0.1.dsc Size/MD5: 576 c9d9bf92c8460d314cb3320666b01294 http://security.ubuntu.com/ubuntu/pool/main/t/tar/tar_1.15.1.orig.tar.gz Size/MD5: 2204322 d87021366fe6488e9dc398fcdcb6ed7d amd64 architecture (Athlon64, Opteron, EM64T Xeon) http://security.ubuntu.com/ubuntu/pool/main/t/tar/tar_1.15.1-2ubuntu0.1_amd64.deb Size/MD5: 531590 9f7a550698b0a138f4d92ec06ecfec96 i386 architecture (x86 compatible Intel/AMD) http://security.ubuntu.com/ubuntu/pool/main/t/tar/tar_1.15.1-2ubuntu0.1_i386.deb Size/MD5: 519510 fd362a5872f6924e491e2caf7639162b powerpc architecture (Apple Macintosh G3/G4/G5) http://security.ubuntu.com/ubuntu/pool/main/t/tar/tar_1.15.1-2ubuntu0.1_powerpc.deb Size/MD5: 533538 c8148419548837909a81da6983af2964 signature.asc Description: Digital 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: Reported Google Vuln
nodialtone wrote: > Google funzies. > > [Snip] > [snip] > > Reference: > > http://seclists.org/lists/fulldisclosure/2006/Feb/0553.html Ok, I give up. Why are you posting a report to the full-disclosure list to announce a post that was posted to... the full-disclosure list? Is this some kind of mail-loop joke? 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/
[Full-disclosure] funny :-)
Check this out: http://seclists.org/lists/fulldisclosure/2006/Feb/0591.html ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Secunia Research: WinACE ARJ Archive Handling Buffer Overflow
== Secunia Research 23/02/2006 - WinACE ARJ Archive Handling Buffer Overflow - == Table of Contents Affected Software1 Severity.2 Description of Vulnerability.3 Solution.4 Time Table...5 Credits..6 References...7 About Secunia8 Verification.9 == 1) Affected Software * WinACE Version 2.60 Prior versions may also be affected. == 2) Severity Rating: Moderately Critical Impact: System access Where: Remote == 3) Description of Vulnerability Secunia Research has discovered a vulnerability in WinACE, which can be exploited by malicious people to compromise a user's system. The vulnerability is caused due to a boundary error when reading an overly large ARJ header block into a fixed-sized heap buffer. This can be exploited to cause a heap-based buffer overflow. Successful exploitation allows execution of arbitrary code when a malicious ARJ archive is opened. == 4) Solution The vulnerability will be fixed in version 2.61. == 5) Time Table 26/10/2005 - Initial vendor notification. 31/10/2005 - Initial vendor reply. 31/10/2005 - Vendor sends fixed version for testing. 15/11/2005 - Vendor reminder. 23/01/2006 - Vendor reminder. 21/02/2006 - Vendor reminder. 23/02/2006 - Public disclosure. == 6) Credits Discovered by Tan Chew Keong, Secunia Research. == 7) References The Common Vulnerabilities and Exposures (CVE) project has assigned CVE-2006-0813 for the vulnerability. == 8) About Secunia Secunia collects, validates, assesses, and writes advisories regarding all the latest software vulnerabilities disclosed to the public. These advisories are gathered in a publicly available database at the Secunia website: http://secunia.com/ Secunia offers services to our customers enabling them to receive all relevant vulnerability information to their specific system configuration. Secunia offers a FREE mailing list called Secunia Security Advisories: http://secunia.com/secunia_security_advisories/ == 9) Verification Please verify this advisory by visiting the Secunia website: http://secunia.com/secunia_research/2005-67/advisory/ Complete list of vulnerability reports published by Secunia Research: http://secunia.com/secunia_research/ == ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Adobe Macromedia ShockWave Code Execution
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Just redirecting to an interesting advisory I have found crawling zdi website and surprised to not see it on FD so here it is, credits to Peter Vreugdenhil http://www.zerodayinitiative.com/advisories/ZDI-06-002.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) iQIVAwUBQ/3mLK+LRXunxpxfAQKNNxAAniihg4EO+haFeQj+DWZKUAaEWD7AfNYE 1W0rrU/ouPct6NGBxBkQA3v3QV8VLrBuaq0ZAC5x4V6vt2Q5rw3oVEkb26li1z0a BkpoIx1hWe1sYvk05RRCNdB6IC70f8pP+CnHHutLb73ETQrYgQohayOMoNi7eYPd nFefEt/XBQaMzzzHfLsLslsXb/sGK3Vk4t5F8TXYvVvlbtBuu7azU/VnqnkUddbJ TIWD8+giK7IH84jCZ8GUAS0wnu4NczVf5CrDXDz9+xaL6Ns38zNSuj8cwEEpthqN zdbUSO+l0i+ey80tn22+ju5RsPS9FosE8KTxYLvllAFkfW2qkultpOGU+11LYW9Y zGqKPLRNoZtiTnxDkujvV/kNUIHwEv9SAE5QYyBV3Wq0sLCRhOTivx6/jaqX0WE0 aD7kwSqFBxHQalPWKlDPz1h6AXMcivHHwALRfafwXtD4T7UQH5JgLvVOcYQ8Miil vdT9fi2kJugblm1IRhvG19NS0QzPGKz51Um0bT8bXT/gUWewvxItMXXqzbLBcvlx QhI0a4qENrGI0ci5mMhJefkL8YFPylUcUsnynwfNUVpS88Tf0+USCuQu4ma0wVzx RR8S6niaXTcXPHvwkclB54YA+oeVql/0eDhHOAUQEbomlcVCg6JL0L0o4cMQbrIL 3T6EtK2H5gY= =baCB -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] ZDI-06-002: Adobe Macromedia ShockWave Code Execution
ZDI-06-002: Adobe Macromedia ShockWave Code Execution http://www.zerodayinitiative.com/advisories/ZDI-06-002.html February 23, 2006 -- CVE ID: CVE-2005-3525 -- Affected Vendor: Adobe Macromedia -- Affected Products: Macromedia Shockwave Installer -- TippingPoint(TM) IPS Customer Protection: TippingPoint IPS customers have been protected against this vulnerability since November 22, 2005 by Digital Vaccine protection filter ID 3934. For further product information on the TippingPoint IPS: http://www.tippingpoint.com -- Vulnerability Details: This vulnerability allows remote attackers to execute arbitrary code on vulnerable installations of Adobe Macromedia Shockwave. Exploitation requires the target to visit a malicious web site. This specific flaw exists within the ActiveX control with CLSID 166B1BCA-3F9C-11CF-8075-44455354. Specifying large values for two specific parameters to this control results in an exploitable stack based buffer overflow. Due to the nature of this vulnerability, the target user is not required to have fully completed an installation of Shockwave to be vulnerable. -- Vendor Response: Adobe has fixed the issue in the Shockwave Player ActiveX installer. Since the vulnerability occurs in the installer, no action needs to be taken by current Macromedia Shockwave Player by Adobe customers. Customers downloading and installing the latest Shockwave Player are no longer vulnerable with the updated Shockwave Player ActiveX installer. -- Disclosure Timeline: 2005.11.22 - Vulnerability reported to vendor 2005.11.22 - Digital Vaccine released to TippingPoint customers 2006.02.21 - Vulnerability information provided to ZDI security partners 2006.02.23 - Coordinated public release of advisory -- Credit: This vulnerability was discovered by Peter Vreugdenhil. -- About the Zero Day Initiative (ZDI): Established by TippingPoint, a division of 3Com, The Zero Day Initiative (ZDI) represents a best-of-breed model for rewarding security researchers for responsibly disclosing discovered vulnerabilities. Researchers interested in getting paid for their security research through the ZDI can find more information and sign-up at: http://www.zerodayinitiative.com The ZDI is unique in how the acquired vulnerability information is used. 3Com does not re-sell the vulnerability details or any exploit code. Instead, upon notifying the affected product vendor, 3Com provides its customers with zero day protection through its intrusion prevention technology. Explicit details regarding the specifics of the vulnerability are not exposed to any parties until an official vendor patch is publicly available. Furthermore, with the altruistic aim of helping to secure a broader user base, 3Com provides this vulnerability information confidentially to security vendors (including competitors) who have a vulnerability protection or mitigation product. ___ 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] HYSA-2006-003 Oi! Email Marketing 3.0 SQL Injection
-- HYSA-2006-003 h4cky0u.org Advisory 012--Date - Thu Feb 24 2006 TITLE:== Oi! Email Marketing 3.0 SQL Injection SEVERITY:= High SOFTWARE:= Oi! Email Marketing 3.0. Prior versions maybe affected INFO:= Oi Email Marketing System is a Linux compatible application that can be a stand-alone product or can be integrated into Mambo 2002 content management system. It uses a powerful database which resides on your webserver and allows complete control over all your subscribers, campaigns and emails. Support Website : www.miro.com.au DESCRIPTION: Oi Email Marketing System is prone to an SQL injection vulnerability. This issue is due to a failure in the index.php script of the application to properly sanitize user-supplied input before using it in SQL queries. Successful exploitation could result in a compromise of the application, disclosure or modification of data, or may permit an attacker to exploit vulnerabilities in the underlying database implementation. POC: First go to http://www.site.com/oi/index.php In this login page provide the following inputs: Username : username' OR ' Password : ' OR ' Note : here username should be a valid user registered on the site (generally admin) Also, if a 'superadministrator'login is found and sucessfully exploited the server's ftp password can be found by clicking 'Configuration' and viewing the pages source: (It's hidden by *) Password VENDOR STATUS= Vendor was contacted repeatedly but no response received till date. FIX: No fix available as of date. CREDITS: - This vulnerability was discovered and researched by - Illuminatus of h4cky0u Security Forums. Mail : illuminatus85 at gmail dot com Web : http://www.h4cky0u.org - Co Researcher - h4cky0u of h4cky0u Security Forums. Mail : h4cky0u at gmail dot com Web : http://www.h4cky0u.org ORIGINAL ADVISORY:== http://www.h4cky0u.org/advisories/HYSA-2006-003-oi-email.txt -- http://www.h4cky0u.org(In)Security at its best... ___ 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: How hackers cause damage... was Vulnerabilites in new laws on computer hacking
Craig Wright wrote: > Cyber-trespass leaves one in a state of doubt. It is commonly stated > that the only manner of recovery from a system compromise is to > rebuild the host. Don't you mean that the trespass disrupts the condition of denial and neglect that normally exists surrounding any network of programmable computers? The 'state of doubt' is no different post-trespass than it was beforehand, what has changed is the emotional condition of the property owner. After recovery steps to rebuild the host, there is again a 'state of doubt' and it is just as substantial as it was before the trespass incident caused everyone emotional trauma. We must build computer systems that separate the act of installing and executing software from the act of depositing data on read/write media. Executable code must not be stored on read/write media. At least not the same media to which data is written, and access to write data to software storage must not be possible through the execution of software; at least not software executing on the same CPU as already-installed software. Our CPUs need a mechanism to verify that the machine code instructions being executed have been previously authorized for execution by the CPU, i.e. the machine code is part of software that has been purposefully installed to a protected software storage separate (logically, at least, and both physically and logically separated at best) through actions that could not have been simulated or duplicated by the execution of machine code at runtime on the system's primary CPU. The worst-case scenario of 'repair' and 'recovery' from any intrusion event should be verification of the integrity of protected storage, restore from backup of data storage, analysis of data processing and network traffic logs to ascertain the mode of intrusion (if possible) and reboot of the affected box with a staged reintroduction of the services that box previously provided (if you just re-launch all of the services being exposed by the box then it is just as vulnerable as before to whatever attack resulted in the intrusion, so you start from the most-locked-down condition and add services one at a time, monitoring for a period of time at each step). Depending on the length of time one is willing to monitor the box as it is staged into deployment again after recovery, and depending on the tools put into place to enable verification of the authenticity and 'correctness' of the machine code found to be present on the protected storage where software is installed, 'recovery' from any incident can be almost immediate, requiring little more than a reboot (the steps for which could also be optimized in a well-built secure computer system, since the objective really is nothing more than wiping all RAM and re-reading machine code from the protected storage after integrity verification is complete) ... All of the 'damage' and 'vulnerabilities' you're talking about stem directly from very bad business decisions made by owners of computer systems and from authors of software made to run on those computer systems. Hackers can be made irrelevant, and virtually all significant damage from 'intrusion' can be prevented in advance, by putting a stop to the world's addiction to the installation and execution of arbitrary code. The problem is that the computer industry has been built around providing financial rewards to the businesses that can get as many copies of their code executing as possible, and security barriers that curtail access to this cash generating machine would kill 75% of the existing computer industry. I say let 'em die. Give us secure computing, and may every company that intentionally harms people for profit die a horrible and painful death that takes as many of its investors with it as possible in the process! Sincerely, Jason Coombs [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] Re: How hackers cause damage... was Vulnerabilites in new laws on computer hacking
Jason Coombs wrote: > Craig Wright wrote: > > Cyber-trespass leaves one in a state of doubt. It is commonly stated > > that the only manner of recovery from a system compromise is to > > rebuild the host. > > Don't you mean that the trespass disrupts the condition of denial and > neglect that normally exists surrounding any network of programmable > computers? > > The 'state of doubt' is no different post-trespass than it was > beforehand, what has changed is the emotional condition of the > property owner. After recovery steps to rebuild the host, there is > again a 'state of doubt' and it is just as substantial as it was > before the trespass incident caused everyone emotional trauma. I disagree here. If you are suggesting that everyone lives in a 'state of doubt' then you are incorrect. Fact is, many people don't understand that a threat even exists. Those people live in ignorance, and as such, there is no 'state of doubt', there is just bliss. > We must build computer systems that separate the act of installing and > executing software from the act of depositing data on read/write media. What the heck are you talking about? We must? Who's we? I sure didn't get the memo! Did you fill out your TPS report? Can you clarify? > > Executable code must not be stored on read/write media. At least not > the same media to which data is written, and access to write data to > software storage must not be possible through the execution of > software; at least not software executing on the same CPU as > already-installed software. No offense, but are you on crack? Everything is a file, even an executable. If you can't read the damn thing how are you going to run it? Hell, an operating system is just a bunch of files... you're not making any sense. > > Our CPUs need a mechanism to verify that the machine code instructions > being executed have been previously authorized for execution by the > CPU, i.e. the machine code is part of software that has been > purposefully installed to a protected software storage separate > (logically, at least, and both physically and logically separated at > best) through actions that could not have been simulated or duplicated > by the execution of machine code at runtime on the system's primary CPU. What in the hell are you talking about again? Are you suggesting that we should check every single possible instruction before it is executed? What about the latency that this would cause? Your theory is far from practical. Are you just trying to sound smart or something? > > The worst-case scenario of 'repair' and 'recovery' from any intrusion > event should be verification of the integrity of protected storage, > restore from backup of data storage, analysis of data processing and > network traffic logs to ascertain the mode of intrusion (if possible) > and reboot of the affected box with a staged reintroduction of the > services that box previously provided (if you just re-launch all of > the services being exposed by the box then it is just as vulnerable as > before to whatever attack resulted in the intrusion, so you start from > the most-locked-down condition and add services one at a time, > monitoring for a period of time at each step). VMware baby! By the way, do you follow this methodology? > > Depending on the length of time one is willing to monitor the box as > it is staged into deployment again after recovery, and depending on > the tools put into place to enable verification of the authenticity > and 'correctness' of the machine code found to be present on the > protected storage where software is installed, 'recovery' from any > incident can be almost immediate, requiring little more than a reboot > (the steps for which could also be optimized in a well-built secure > computer system, since the objective really is nothing more than > wiping all RAM and re-reading machine code from the protected storage > after integrity verification is complete) ... I hate the way you write, I can hardly understand what kind of craziness you are proposing. > > All of the 'damage' and 'vulnerabilities' you're talking about stem > directly from very bad business decisions made by owners of computer > systems and from authors of software made to run on those computer > systems. Hackers can be made irrelevant, and virtually all significant > damage from 'intrusion' can be prevented in advance, by putting a stop > to the world's addiction to the installation and execution of > arbitrary code. The problem is that the computer industry has been > built around providing financial rewards to the businesses that can > get as many copies of their code executing as possible, and security > barriers that curtail access to this cash generating machine would > kill 75% of the existing computer industry. Interesting rant man, very interesting. Security is nothing more than a balance between limited functionality and business requirements. Your secure world will never exist because the industry, hell t
Re: [Full-disclosure] Re: How hackers cause damage... was Vulnerabilites in new laws on computer hacking
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 And people say _I_ think in black and white...? Jason Coombs wrote: > We must build computer systems that separate the act of installing and > executing software from the act of depositing data on read/write media. > > Executable code must not be stored on read/write media. At least not the > same media to which data is written, and access to write data to > software storage must not be possible through the execution of software; > at least not software executing on the same CPU as already-installed > software. > > Our CPUs need a mechanism to verify that the machine code instructions > being executed have been previously authorized for execution by the CPU, > i.e. the machine code is part of software that has been purposefully > installed to a protected software storage separate (logically, at least, > and both physically and logically separated at best) through actions > that could not have been simulated or duplicated by the execution of > machine code at runtime on the system's primary CPU. > > The worst-case scenario of 'repair' and 'recovery' from any intrusion > event should be verification of the integrity of protected storage, > restore from backup of data storage, analysis of data processing and > network traffic logs to ascertain the mode of intrusion (if possible) > and reboot of the affected box with a staged reintroduction of the > services that box previously provided (if you just re-launch all of the > services being exposed by the box then it is just as vulnerable as > before to whatever attack resulted in the intrusion, so you start from > the most-locked-down condition and add services one at a time, > monitoring for a period of time at each step). [snip remainder of delusional plan for world peace and secure computing] There are several fundamental problems with this statement. First of all, not all compromises are actual compromises of the systems themselves. Not all exploits achieve or require the introduction of malicious, unauthorized code. For instance, take a web server that offers up confidential information when faced with some type of path traversal sequence (IIS extended unicode, anyone?). The code that web server is executing is 100% authorized, because it all lies within an installed component. The problem is that the authorized code is flawed in such a way that it permits access to *data* that it should not. That could be something like the social security numbers stored in your flat file database, your site's password file, etc. That attack just succeeded... potentially compromising millions of credit card numbers, thousands of user accounts or [insert apocalypse] _without ever relying on the ability to introduce foreign code_. Further, this "dual-channel" system (for lack of a better term) that you propose would mean fundamentally redesigning computing in a way that is not readily apparent. Fine, store all your executable code on a second drive and bar all writes to the executable volume from within the protected system. The basic methods of doing this are there with file system ACLs on a high level and read-only/tamper-resistant media on a low-level. Granted, it would require a sizable amount of reconfiguration to implement with today's PC operating systems, but it is possible. That problem is solved -- preventing the alteration of the execution environment from a base install. However, the very mythical notion espoused by those who consider their code "secure" is the idea that the base install is safe. In the majority of cases, this is not anywhere near true. So, there's still the possibility of buffer overrun attacks and other "code injection" scenarios that rely on the ability to alter some portion of the system's primary memory. You can make a big stride against that by isolating the execution environment from unsanitized run-time information (data) in memory either using flagging (NX/XD) or a more intrusive physical isolation (multiple buses, different RAM locations for code/data, etc.) However, this fails to stop the possibilities for the execution of TRUSTED code in an unsafe environment. A classic example of this is what is often mis-labeled "return-into-libc" attacks. A vulnerability in software is exploited such that normally safe (and ostensibly trusted) code is executed in an unsafe context. As far as I can tell, the isolation of data from "trusted" code would not solve this. For that to be remedied, you'd fundamentally have to limit the TCB to code that could be trusted to execute in *ANY* environment. The problem of security in the first place is that such code is non-existent in today's world and not achievable in the forseeable future, due to inherent flaws and imperfections in the logic of the human species designing the crap. So, this "solution" that you propose fails to completely solve one of the most well-known security threats of our time: buffer overruns. In order to s
[Full-disclosure] Re: How hackers cause damage... was Vulnerabilites in new laws on computer hacking
Craig Wright wrote: The "state of doubt" I was referring to is the condition of determination associated with knowledge that a system has been attacked. The determination that the attacker was benign or malevolent leaves one in doubt Your sage wisdom on the subject of helping people respond appropriately to attacks, crime and fraud (insider/outsider/etc) is duly acknowledged. We all have 'knowledge' that our systems have been attacked based on the fact that software originating from Microsoft is present on our boxes, and the fact that microprocessors designed only for stand-alone use (absent data communications or other untrustworthy I/O) have been improperly and irresponsibly thrust onto the marketplace by Intel, AMD, et al -- companies with the technical awareness of the proper solution to the problem who withhold not only the solution but also withhold disclosure of their knowledge of the problem. Sincerely, Jason Coombs [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/
[Full-disclosure] [FLSA-2006:162750] Updated sudo packages fix security issue
- Fedora Legacy Update Advisory Synopsis: Updated sudo packages fix security issue Advisory ID: FLSA:162750 Issue date:2006-02-23 Product: Red Hat Linux, Fedora Core Keywords: Bugfix CVE Names: CVE-2005-1993 - - 1. Topic: An updated sudo package is available that fixes a race condition in sudo's pathname validation. The sudo (superuser do) utility allows system administrators to give certain users the ability to run commands as root with logging. 2. Relevant releases/architectures: Red Hat Linux 7.3 - i386 Red Hat Linux 9 - i386 Fedora Core 1 - i386 Fedora Core 2 - i386 3. Problem description: A race condition bug was found in the way sudo handles pathnames. It is possible that a local user with limited sudo access could create a race condition that would allow the execution of arbitrary commands as the root user. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2005-1993 to this issue. Users of sudo should update to this updated package, which contains a backported patch and is not vulnerable to this issue. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. To update all RPMs for your particular architecture, run: rpm -Fvh [filenames] where [filenames] is a list of the RPMs you wish to upgrade. Only those RPMs which are currently installed will be updated. Those RPMs which are not installed but included in the list will not be updated. Note that you can also use wildcards (*.rpm) if your current directory *only* contains the desired RPMs. Please note that this update is also available via yum and apt. Many people find this an easier way to apply updates. To use yum issue: yum update or to use apt: apt-get update; apt-get upgrade This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. This assumes that you have yum or apt-get configured for obtaining Fedora Legacy content. Please visit http://www.fedoralegacy.org/docs for directions on how to configure yum and apt-get. 5. Bug IDs fixed: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=162750 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/sudo-1.6.5p2-2.3.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/sudo-1.6.5p2-2.3.legacy.i386.rpm Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/sudo-1.6.6-3.3.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/sudo-1.6.6-3.3.legacy.i386.rpm Fedora Core 1: SRPM: http://download.fedoralegacy.org/fedora/1/updates/SRPMS/sudo-1.6.7p5-2.3.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/1/updates/i386/sudo-1.6.7p5-2.3.legacy.i386.rpm Fedora Core 2: SRPM: http://download.fedoralegacy.org/fedora/2/updates/SRPMS/sudo-1.6.7p5-26.2.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/2/updates/i386/sudo-1.6.7p5-26.2.legacy.i386.rpm 7. Verification: SHA1 sum Package Name - 5eed8171a2be78f8a03de987b86220b1c8ecb9d4 redhat/7.3/updates/i386/sudo-1.6.5p2-2.3.legacy.i386.rpm f1fdc4b82456cf66f89764ec7f9c0909a0603805 redhat/7.3/updates/SRPMS/sudo-1.6.5p2-2.3.legacy.src.rpm 7a84e2d96bba56142ca8c6dec2603577e31b2072 redhat/9/updates/i386/sudo-1.6.6-3.3.legacy.i386.rpm 4aca97be1c9e5f61efa1165955eb219fce3af70e redhat/9/updates/SRPMS/sudo-1.6.6-3.3.legacy.src.rpm 4e7b55e41c355e51b4cdd3a820a6d5c94df43fdc fedora/1/updates/i386/sudo-1.6.7p5-2.3.legacy.i386.rpm 6843f6ee7792e8c63f1034107a4a4e464a613798 fedora/1/updates/SRPMS/sudo-1.6.7p5-2.3.legacy.src.rpm 954a6e7098b7e86e7bc1f1532a72f8a3dab32380 fedora/2/updates/i386/sudo-1.6.7p5-26.2.legacy.i386.rpm 82c884d6bcff123dd510ffdb8a0d81ce63606364 fedora/2/updates/SRPMS/sudo-1.6.7p5-26.2.legacy.src.rpm These packages are GPG signed by Fedora Legacy for security. Our key is available from http://www.fedoralegacy.org/about/security.php You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the sha1sum with the following command: sha1sum 8. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1993 9. Contact: The Fedora Legacy security contact is <[EMAIL PROTECTED]>. More project details at http://www.fedoralegacy.org - signature.asc Description: OpenPGP digital signature ___ Full-Disclosure - We believe in it. Cha
[Full-disclosure] [FLSA-2006:180036-1] Updated mozilla packages fix security issues
- Fedora Legacy Update Advisory Synopsis: Updated mozilla packages fix security issues Advisory ID: FLSA:180036-1 Issue date:2006-02-23 Product: Red Hat Linux, Fedora Core Keywords: Bugfix CVE Names: CVE-2005-4134 CVE-2006-0292 CVE-2006-0296 - - 1. Topic: Updated mozilla packages that fix several security bugs are now available. Mozilla is an open source Web browser, advanced email and newsgroup client, IRC chat client, and HTML editor. 2. Relevant releases/architectures: Red Hat Linux 7.3 - i386 Red Hat Linux 9 - i386 Fedora Core 1 - i386 Fedora Core 2 - i386 Fedora Core 3 - i386, x86_64 3. Problem description: Igor Bukanov discovered a bug in the way Mozilla's Javascript interpreter dereferences objects. If a user visits a malicious web page, Mozilla could crash or execute arbitrary code as the user running Mozilla. The Common Vulnerabilities and Exposures project assigned the name CVE-2006-0292 to this issue. moz_bug_r_a4 discovered a bug in Mozilla's XULDocument.persist() function. A malicious web page could inject arbitrary RDF data into a user's localstore.rdf file, which can cause Mozilla to execute arbitrary javascript when a user runs Mozilla. (CVE-2006-0296) A denial of service bug was found in the way Mozilla saves history information. If a user visits a web page with a very long title, it is possible Mozilla will crash or take a very long time the next time it is run. (CVE-2005-4134) Users of Mozilla are advised to upgrade to these updated packages, which contain backported patches to correct these issues. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. To update all RPMs for your particular architecture, run: rpm -Fvh [filenames] where [filenames] is a list of the RPMs you wish to upgrade. Only those RPMs which are currently installed will be updated. Those RPMs which are not installed but included in the list will not be updated. Note that you can also use wildcards (*.rpm) if your current directory *only* contains the desired RPMs. Please note that this update is also available via yum and apt. Many people find this an easier way to apply updates. To use yum issue: yum update or to use apt: apt-get update; apt-get upgrade This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. This assumes that you have yum or apt-get configured for obtaining Fedora Legacy content. Please visit http://www.fedoralegacy.org/docs for directions on how to configure yum and apt-get. 5. Bug IDs fixed: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180036 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/mozilla-1.7.12-0.73.3.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/mozilla-1.7.12-0.73.3.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/mozilla-chat-1.7.12-0.73.3.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/mozilla-devel-1.7.12-0.73.3.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/mozilla-dom-inspector-1.7.12-0.73.3.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/mozilla-js-debugger-1.7.12-0.73.3.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/mozilla-mail-1.7.12-0.73.3.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/mozilla-nspr-1.7.12-0.73.3.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/mozilla-nspr-devel-1.7.12-0.73.3.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/mozilla-nss-1.7.12-0.73.3.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/mozilla-nss-devel-1.7.12-0.73.3.legacy.i386.rpm Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/mozilla-1.7.12-0.90.2.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/mozilla-1.7.12-0.90.2.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/mozilla-chat-1.7.12-0.90.2.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/mozilla-devel-1.7.12-0.90.2.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/mozilla-dom-inspector-1.7.12-0.90.2.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/mozilla-js-debugger-1.7.12-0.90.2.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/mozilla-mail-1.7.12-0.90.2.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/mozilla-nspr-1.7.12-0.90.2.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/mozilla-nspr-devel-1.7
[Full-disclosure] [FLSA-2006:180036-2] Updated firefox package fixes security issues
- Fedora Legacy Update Advisory Synopsis: Updated firefox package fixes security issues Advisory ID: FLSA:180036-2 Issue date:2006-02-23 Product: Fedora Core Keywords: Bugfix CVE Names: CVE-2005-4134 CVE-2006-0292 CVE-2006-0296 - - 1. Topic: An updated firefox package that fixes several security bugs is now available. Mozilla Firefox is an open-source web browser, designed for standards compliance, performance and portability. 2. Relevant releases/architectures: Fedora Core 3 - i386, x86_64 3. Problem description: Igor Bukanov discovered a bug in the way Firefox's Javascript interpreter derefernces objects. If a user visits a malicious web page, Firefox could crash or execute arbitrary code as the user running Firefox. The Common Vulnerabilities and Exposures project assigned the name CVE-2006-0292 to this issue. moz_bug_r_a4 discovered a bug in Firefox's XULDocument.persist() function. A malicious web page could inject arbitrary RDF data into a user's localstore.rdf file, which can cause Firefox to execute arbitrary javascript when a user runs Firefox. (CVE-2006-0296) A denial of service bug was found in the way Firefox saves history information. If a user visits a web page with a very long title, it is possible Firefox will crash or take a very long time the next time it is run. (CVE-2005-4134) Users of Firefox are advised to upgrade to this updated package, which contains backported patches to correct these issues. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. To update all RPMs for your particular architecture, run: rpm -Fvh [filenames] where [filenames] is a list of the RPMs you wish to upgrade. Only those RPMs which are currently installed will be updated. Those RPMs which are not installed but included in the list will not be updated. Note that you can also use wildcards (*.rpm) if your current directory *only* contains the desired RPMs. Please note that this update is also available via yum and apt. Many people find this an easier way to apply updates. To use yum issue: yum update or to use apt: apt-get update; apt-get upgrade This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. This assumes that you have yum or apt-get configured for obtaining Fedora Legacy content. Please visit http://www.fedoralegacy.org/docs for directions on how to configure yum and apt-get. 5. Bug IDs fixed: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180036 6. RPMs required: Fedora Core 3: SRPM: http://download.fedoralegacy.org/fedora/3/updates/SRPMS/firefox-1.0.7-1.3.fc3.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/3/updates/i386/firefox-1.0.7-1.3.fc3.legacy.i386.rpm x86_64: http://download.fedoralegacy.org/fedora/3/updates/x86_64/firefox-1.0.7-1.3.fc3.legacy.x86_64.rpm 7. Verification: SHA1 sum Package Name - 3b05d93992aba7369a418d53344250aa275330ac fedora/3/updates/i386/firefox-1.0.7-1.3.fc3.legacy.i386.rpm 850534b4cfa591372d8245808e46378c5923e086 fedora/3/updates/x86_64/firefox-1.0.7-1.3.fc3.legacy.x86_64.rpm a167dc9061c484aa26f89703dc0228883409235e fedora/3/updates/SRPMS/firefox-1.0.7-1.3.fc3.legacy.src.rpm These packages are GPG signed by Fedora Legacy for security. Our key is available from http://www.fedoralegacy.org/about/security.php You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the sha1sum with the following command: sha1sum 8. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-4134 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0292 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0296 9. Contact: The Fedora Legacy security contact is <[EMAIL PROTECTED]>. More project details at http://www.fedoralegacy.org - signature.asc Description: OpenPGP digital 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] Pod Slurping Code
I have been doing some research on Pod-Slurping and have a copy of the Slurp.exe implemented on my IPod. However it does not copy the content, just shows the files that _could_ have been copied. Does anyone on this list have a working copy of slurp.exe or similar code that actually copies the content to the IPod? Thanks Babak signature.asc Description: This is a digitally signed message part _ igxglobal utilizes state of the art technology from PGP to ensure the safeguard of all electronic correspondences. This message could have been secured by PGP Universal. To secure future messages from this sender, please click this link and contact your representative at igxglobal for further information: https://keys.igxglobal.com/b/b.e?r=full-disclosure%40lists.grok.org.uk&n=4Njq7juzEf1Yn9MHjRn9Ow%3D%3D ___ 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: How hackers cause damage... was Vulnerabilites in new laws on computer hacking
Hi Jason First I do agree that vulnerable software is an issue, I also would love to see a world where I was not needed for the skills I peddle. I would like a world where compliance was not necessary, where fraud did not occur... The "state of doubt" I was referring to is the condition of determination associated with knowledge that a system has been attacked. The determination that the attacker was benign or malevolent leaves one in doubt as to the true intentions and thus one has to err towards the side of the assumption that the attack was malign. Please do not let me asperse your passion for fixing the flaws inherent in the world. I wish you all the best on this, but I have become a little more jaded over time. I also teach CAATs based methods to determine corporate financial fraud and accounts fraud as well as the more information security focused risk that this list propagates. People are generally in a state of denial this is true, but why should that be the issue. I preach awareness all the time, yet I would prefer a world where this is not needed. Who do we blame - the victim who did not take adequate care or the criminal? If I walk down a dark alley at night is it my fault if I get mugged? Should it be? It may be ignorant but who are we protecting and what type of society do we want to create? Regards, Craig -Original Message- From: Jason Coombs [mailto:[EMAIL PROTECTED] Sent: 24 February 2006 8:08 To: Craig Wright Cc: security-basics@securityfocus.com; [EMAIL PROTECTED]; Full-Disclosure; bugtraq@securityfocus.com Subject: Re: How hackers cause damage... was Vulnerabilites in new laws on computer hacking Craig Wright wrote: > Cyber-trespass leaves one in a state of doubt. It is commonly stated > that the only manner of recovery from a system compromise is to > rebuild the host. Don't you mean that the trespass disrupts the condition of denial and neglect that normally exists surrounding any network of programmable computers? The 'state of doubt' is no different post-trespass than it was beforehand, what has changed is the emotional condition of the property owner. After recovery steps to rebuild the host, there is again a 'state of doubt' and it is just as substantial as it was before the trespass incident caused everyone emotional trauma. We must build computer systems that separate the act of installing and executing software from the act of depositing data on read/write media. Executable code must not be stored on read/write media. At least not the same media to which data is written, and access to write data to software storage must not be possible through the execution of software; at least not software executing on the same CPU as already-installed software. Our CPUs need a mechanism to verify that the machine code instructions being executed have been previously authorized for execution by the CPU, i.e. the machine code is part of software that has been purposefully installed to a protected software storage separate (logically, at least, and both physically and logically separated at best) through actions that could not have been simulated or duplicated by the execution of machine code at runtime on the system's primary CPU. The worst-case scenario of 'repair' and 'recovery' from any intrusion event should be verification of the integrity of protected storage, restore from backup of data storage, analysis of data processing and network traffic logs to ascertain the mode of intrusion (if possible) and reboot of the affected box with a staged reintroduction of the services that box previously provided (if you just re-launch all of the services being exposed by the box then it is just as vulnerable as before to whatever attack resulted in the intrusion, so you start from the most-locked-down condition and add services one at a time, monitoring for a period of time at each step). Depending on the length of time one is willing to monitor the box as it is staged into deployment again after recovery, and depending on the tools put into place to enable verification of the authenticity and 'correctness' of the machine code found to be present on the protected storage where software is installed, 'recovery' from any incident can be almost immediate, requiring little more than a reboot (the steps for which could also be optimized in a well-built secure computer system, since the objective really is nothing more than wiping all RAM and re-reading machine code from the protected storage after integrity verification is complete) ... All of the 'damage' and 'vulnerabilities' you're talking about stem directly from very bad business decisions made by owners of computer systems and from authors of software made to run on those computer systems. Hackers can be made irrelevant, and virtually all significant damage from 'intrusion' can be prevented in advance, by putting a stop to the world's addiction to the installation and execution of arbitrary code. The problem is that the com
Re: [Full-Disclosure] Insecurity in Finnish parlament (computers)
Olli Haukkovaara sayed: >Your answer below is in fact what I expected - you can not >be sure about this issue, because you can not proof it. I am (pretty darn) sure about the issue, even I cannot provide you with specific facts about some vendors and model numbers. I have received information and talked about the subject with "people" who are into this business. Its like that you would say that Australia exists and I would start to argue against you, that you cannot be sure it exists, because you cannot provide me exact information about the lenght of the coastline of Australia etc. Wake up. Besides, all of this is irrelevant to the subject in hand: Insecurity of TeliaSonera & A5/1 and the fact that our goverment/parlament would need to have some people working in the compsec/infosec section that would understand and care about these issues. -- My computer security & privacy related homepage http://www.markusjansson.net Use HushTools or GnuPG/PGP to encrypt any email before sending it to me to protect our privacy. ___ 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] Taking from 1 is copying. Taking from 2 is Plagiarism.
The below is from the widely respected Slade. Read it. This is just one more nail in the coffing of the Certificate Money Machines. All you CISSP's just because worthless based upon your certifying authority. Can Everything SANS be far behind??? -- Yours, J.A. Terranson [EMAIL PROTECTED] 0xBD4A95BF 'The right of self defence is the first law of nature: in most governments it has been the study of rulers to confine this right within the narrowest limits possible. Wherever standing armies are kept up, and the right of the people to keep and bear arms is, under any colour or pretext whatsoever, prohibited, liberty, if not already annihilated, is on the brink of destruction.' St. George Tucker - Date: Fri, 30 Jul 2004 07:54:11 -0800 From: Rob Slade <[EMAIL PROTECTED]> Subject: REVIEW: "Official [ISC]^2 Guide to the CISSP Exam", Hansche et al. BKOIGTCE.RVW 20040618 "Official (ISC)^2 Guide to the CISSP Exam", Susan Hansche/John Berti/Chris Hare, 2004, 0-8493-1707-X, U$69.95/C$101.50 %A Susan Hansche [EMAIL PROTECTED] %A John Berti [EMAIL PROTECTED] %A Chris Hare [EMAIL PROTECTED], [EMAIL PROTECTED] %C 920 Mercer Street, Windsor, ON N9A 7C2 %D 2004 %G 0-8493-1707-X %I Auerbach Publications %O U$69.95/C$101.50 800-950-1216 [EMAIL PROTECTED] %O http://www.amazon.com/exec/obidos/ASIN/084931707X/robsladesinterne http://www.amazon.co.uk/exec/obidos/ASIN/084931707X/robsladesinte-21 %O http://www.amazon.ca/exec/obidos/ASIN/084931707X/robsladesin03-20 %P 910 p. + CD-ROM %T "Official (ISC)^2 Guide to the CISSP Exam" Once again I have to state a bias in regard to this book. I've known about this book since its inception, I've known and advised the authors, I provided bits of the material, and even contributed one appendix. (The annotated bibliography and references--surprise, surprise.) I was asked to review the chapters while the book was in production. The reason was, of course, that I had reviewed all the other CISSP (Certified Information Systems Security Professional) guides. Specifically, the intent was to ensure that this manual, prepared and supported by (ISC)^2 (International Information Systems Security Certification Consortium) was "head and shoulders" above all the other published works. This volume is not perfect, by any means, but it is the best of the current bunch. Taking material from one source is copying, taking material from two sources is plagiarism, and taking material from many sources is research. This volume has not only research but direct input from a great many sources. Some are mentioned in the acknowledgements, a number of others are to be found on the title page, since sections of major articles from the venerable "Information Security Management Handbook" (cf. BKINSCMH.RVW) were included or used as the basis for parts of the guide. Even this doesn't exhaust the contributions, since much of the work is informed by the material in the (ISC)^2 CBK (Common Body of Knowledge) Review Seminar, and over a hundred individuals have had the chance to augment that content. The result is a breadth and currency of information that exceeds any other guide on the market. Sample questions and exams are eagerly sought by candidates for the CISSP exam. This guide has a significant advantage in this regard: not only do a number of the contributors produce questions for the exam itself (therefore being more than passingly familiar with the style and level of difficulty required), but the CISSP exam committee was also approached for advice and input. No source is able to provide "actual" CISSP exam questions, but the examples provided in this volume are very close in form, mix, degree of difficulty, and concept. The book is not without its faults. The sheer volume of the contributors ensured that topics were covered multiple times, and not all duplicated areas have been amalgamated. In addition, the variety of writing styles can make the text disjointed in places, as it moves from section to section and subject to subject. These factors can make the work difficult and demanding to read and follow. The CISSP exam, as the security field itself, is a changing target, and no book can expect to provide the "best" coverage of the topic indefinitely. As well, security is an immense discipline, and touches on an inordinate number of other areas. This work, however, has come closest to spanning the range of subject matter necessary to challenge the CISSP exam, and is currently the best of the guides. copyright Robert M. Slade, 2004 BKOIGTCE.RVW 20040618 [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://victoria.tc.ca/techrevorhttp://sun.soci.niu.edu/~rslade -- -- Yours, J.A. Terranson [EMAIL PROTECTED] 0xBD4A95BF 'The right of self defence is the first law of nature: in most governments it has been the study of rulers to co
Re: [Full-disclosure] Taking from 1 is copying. Taking from 2 is Plagiarism.
On Thu, 23 Feb 2006 22:59:42 CST, "J.A. Terranson" said: > This is just one more nail in the coffing of the Certificate Money > Machines. All you CISSP's just because worthless based upon your > certifying authority. Actually, it does nothing of the sort. There were study guides before, and this one doesn't change matters. Before this book came out, the cert was basically just saying "This person managed to keep enough security info inside his cranium to pass the exam". And after the book came out, the cert still means the same thing. The bigger question is: "Does knowing enough to pass the exam correspond to having actual security clue?" - but the existence of a new study guide doesn't change the debate on that question. pgptjorMauMne.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] Quarantine your infected users spreading malware
There is a method used in my network to fix this kind of situations and this is called the Spread & Patch system were some machines controlled by me searches the network for common flaws and patch them with microsoft updates therefore reducing the number of newbie zombies. - Original Message - From: "Gadi Evron" <[EMAIL PROTECTED]> To: ; Sent: Monday, February 20, 2006 10:40 PM Subject: [Full-disclosure] Quarantine your infected users spreading malware > Many ISP's who do care about issues such as worms, infected users > "spreading the love", etc. simply do not have the man-power to handle > all their infected users' population > > It is becoming more and more obvious that the answer may not be at the > ISP's doorstep, but the ISP's are indeed a critical part of the > solution. What their eventual role in user safety will be I can only > guess, but it is clear (to me) that this subject is going to become a > lot "hotter" in coming years. > > Aunty Jane (like Dr. Alan Solomon (drsolly) likes to call your average > user) is your biggest risk to the Internet today, and how to fix the > user non of us have a good idea quite yet. Especially since it's not > quite one as I put in an Heinlein quote below. > > Some who are user/broadband ISP's (not say, tier-1 and tier-2's who > would be against it: "don't be the Internet's Firewall") are blocking > ports such as 139 and 445 for a long time now, successfully preventing > many of their users from becoming infected. This is also an excellent > first step for responding to relevant outbreaks and halting their progress. > > Philosophy aside, it works. It stops infections. Period. > > Back to the philosophy, there are some other solutions as well. Plus, > should this even be done? > > One of them has been around for a while, but just now begins to mature: > Quarantining your users. > > Infected users quarantine may sound a bit harsh, but consider; if a user > is indeed infected and does "spread the joy" on your network as well as > others', and you could simply firewall him (or her) out of the world > (VLAN, other solutions which may be far better) letting him (or her) go > only to a web page explaining the problem to them, it's pretty nifty. > > As many of us know, handling such users on tech support is not very > cost-effective to ISP's, as if a user makes a call the ISP already > losses money on that user. Than again, paying abuse desk personnel just > so that they can disconnect your users is losing money too. > > Which one would you prefer? > > Jose (Nazario) points to many interesting papers on the subject on his > blog: http://www.wormblog.com/papers/ > > Is it the ISP's place to do this? Should the ISP do this? Does the ISP > have a right to do this? > > If the ISP is nice enough to do it, and users know the ISP might. Why not? > > This (as well as port blocking) is more true for organizations other > than ISP's, but if they are indeed user/broadband ISP's, I see this as > both the effective and the ethical thing to do if the users are notified > this might happen when they sign their contracts. Then all the "don't be > the Internet's firewall" debate goes away. > > I respect the "don't be the Internet's firewall issue", not only for the > sake of the cause but also because friends such as Steven Bellovin and > other believe in them a lot more strongly than I do. Bigger issues such > as the safety of the Internet exist now. That doesn't mean user rights > are to be ignored, but certainly so shouldn't ours, especially if these > are mostly unaffected? > > I believe both are good and necessary solutions, but every organization > needs to choose what is best for it, rather than follow some > pre-determined blueprint. What's good for one may be horrible for another. > > "You don't approve? Well too bad, we're in this for the species boys and > girls. It's simple numbers, they have more and every day I have to make > decisions that send hundreds of people, like you, to their deaths." -- > Carl Jenkins, Starship Trooper, the movie. > I don't think the second part of the quote is quite right (to say the > least), but I felt bad leaving it out, it's Heinlein after all... anyone > who claims he is a fascist though will have to deal with me. :) > This isn't only about users, it's about the bad guys and how they > out-number us, too. They have far better cooperation to boot. > > There are several such products around and they have been discussed > before, but I haven't tried them myself as of yet, so I can't really > recommend any of them. Can you? > > I'll update on these as I find out more on: http://blogs.securiteam.com > > This write-up can be found here: > http://blogs.securiteam.com/index.php/archives/312 > > Gadi. > > -- > http://blogs.securiteam.com/ > > "Out of the box is where I live". > -- Cara "Starbuck" Thrace, Battlestar Galactica. > ___ > Full-Disclosure - We believe in it. > Charter: http://lists.gro
Re: [Full-disclosure] Re: Reported Google Vuln
Dave Korn wrote: > nodialtone wrote: > >>Google funzies. >> >>[Snip] >> >>Reference: >> >>http://seclists.org/lists/fulldisclosure/2006/Feb/0553.html > > > Ok, I give up. Why are you posting a report to the full-disclosure list > to announce a post that was posted to... the full-disclosure list? Is this > some kind of mail-loop joke? > > > cheers, > DaveK my head just exploded. guts hurt from laughing. thanks dave. the dreaded fibonacci vulnerability!! it gets worse with each posting! ahh! time for sleep... randy ___ 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] Insecurity in Finnish parlament (computers)
I'm discussing with base station vendors about this A5/1 issue. I'll return to this topic when I get answers from all of them. It may take some time because many people have their winter vacations during this and next week - in fact I'm too on vacation next week and will not think about these issues too much during that time ;-) But after that I hope this thing gets clear. -- Regards, Olli ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
