Re: [Full-disclosure] Google Talk Denial of Service - BenjiBug
If you successfully compromise the account of the victim user you can just modify the update version file, the signature, and the URL of the executable by changing the following Registry Keys: HKEY_CURRENT_USER\Software\Google\Google Talk\Autoupdate\AvailableURL HKEY_CURRENT_USER\Software\Google\Google Talk\Autoupdate\Signature HKEY_CURRENT_USER\Software\Google\Google Talk\Autoupdate\UpdateURL With this keys you should be able to download your spyware file with its own signature so that Google Talk doesn't complain. You can even set when the next update will take place: HKEY_CURRENT_USER\Software\Google\Google Talk\Autoupdate\NextUpdate I haven't tested this to be honest, but I believe it should work since these are the locations where Google Talk saves all the settings you discussed on your post. Regards, pagvac (Adrian Pastor) www.ikwt.com James Evans wrote: Title: Google Talk Denial of Service - BenjiBug Reported Date: October 15, 2005 Public Disclosure: November 22, 2005 Status: Vendor contacted. Unpatched. Software which automatically updates itself is often a good idea - especially where home users are concerned. It is often impossible to patch their systems otherwise. But automatic update mechanisms must be designed and implemented in ways which prevent malicious attackers from installing malware. Google Talk includes the ability to automatically update itself - a feature which cannot be disabled. Google Talk connects at random intervals (about once every day or so in testing) to dl.google.com via HTTP and fetches a .txt file (http://dl.google.com/googletalk/google-talk-versioncheck.txt) which lists the current version of Google Talk, as well as a digital signature of the new installer executable. If the version number is greater than the version currently running, Google Talk will download the .exe and, after checking its authenticity, execute it to automatically update. Assuming a user's DNS cache can be poisoned, a denial of service attack is possible. Thanks to the digital signature, malware will not execute. Yet, it is possible to force Google Talk to download a large file which it will then analyze to determine whether the signature matches. This will consume 100% CPU and large amounts of memory, resulting in an unstable machine which requires a reboot in some cases. It is also possible to plant incriminating files on a user's machine, as the files are at first downloaded and saved to the Temporary Internet Files directory before they are verified and moved to Google Talk's data directory. Google can patch this by checking the file size of the downloaded executable to ensure that it is within the range of a normal updater .exe. Addendum: Although Launch-Target can be manipulated to cause Google Talk to execute a file other than the one downloaded from the URL field, it will not execute files outside of the C:\Program Files\Google\Google Talk\googletalk-[version] directory, so this seems useless as an attack vector. Google Talk's request to Google's servers is as follows: GET /googletalk/google-talk-versioncheck.txt?auv=1r=4up=30p=wma=5mi=1b=2600sp=ServicePack2as=googletalkpv=1.0.0.76 ma = major version number, mi = minor version number, b = build -James Evans ___ 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] Cisco PIX TCP Connection Prevention
Arhont Ltd.- Information Security Arhont Advisory by: Konstantin V. Gavrilenko (http://www.arhont.com) Advisory: Cisco PIX TCP Connection Prevention Class: design bug Version:Tested on PIX515E, PIX OS version 6.3(3) Model Specific: Other versions might have the same bug DETAILS: In a situation when a host is located on the trusted side of the network behind the PIX firewall, there is a possibility to prevent a new legitimate TCP connection to be established to the host located on the other side of the firewall. In order to execute such an attack, an attacker would send a specifically crafted TCP packet with a set incorrect cheksum through the PIX firewall pretending to be originated from a legitimate host. S/he would need to specify the source and destination IP and port, and once such packet is received by the PIX firewall, there is no possibility to establish a new TCP session with the credentials specified in the malicious packet. The downtime of the connection is around 2 minutes 2 seconds, after which the new connection can be established again and the PIX resumes the normal operation mode. Such attack does not affect the connections that are already established through the PIX. Although, it would take a lot of packets to disrupt the communication between the hosts completely, we assume that the attacker's aim is to prevent the communication to a specific service on the remote hosts, e.g. SSH, SMTP, TCP-syslog, and it takes around 15 seconds to generate and spit out 65535 packets with a custom source port on a 100mbit lan. The attack was tested on a PIX firewall 515E with 64Mb of RAM performing a NAT on the external interface, the configuration file is attached. The custom packet can be easily generated by hping2 as following: arhontus / # hping -c 1 -S -s 31337 -k -b -p 22 192.168.xx.xxx Allowing just one packet through the PIX FW will block the forthcoming packet from port 31337 to port 22 for a duration of just over 2 minutes. The sample perl script that is used to automate source port increments and generate malicious packets is attached. RISK FACTOR: Medium WORKAROUNDS: Await Cisco advice on details of the workarounds. COMMUNICATION HISTORY: PSIRT notified on 10/10/2005 P release on 22/11/2005 ADDITIONAL INFORMATION: pixdos.pl tool is attached to this e-mail. *According to the Arhont Ltd. policy, all of the found vulnerabilities and security issues will be reported to the manufacturer at least 7 days before releasing them to the public domains (such as CERT and BUGTRAQ). If you would like to get more information about this issue, please do not hesitate to contact Arhont team on [EMAIL PROTECTED] APPENDIX 1. Show Tech output: pixfw# sh tech Cisco PIX Firewall Version 6.3(3) Cisco PIX Device Manager Version 3.0(1) Compiled on Wed 13-Aug-03 13:55 by morlee pixfw up 44 days 19 hours Hardware: PIX-515E, 64 MB RAM, CPU Pentium II 433 MHz Flash E28F128J3 @ 0x300, 16MB BIOS Flash AM29F400B @ 0xfffd8000, 32KB 0: ethernet0: address is 0090.2799.118f, irq 10 1: ethernet1: address is 0090.2799.11b6, irq 11 2: ethernet2: address is 00a4.0080.d29c, irq 11 Licensed Features: Failover:Disabled VPN-DES: Enabled VPN-3DES-AES:Disabled Maximum Physical Interfaces: 3 Maximum Interfaces: 5 Cut-through Proxy: Enabled Guards: Enabled URL-filtering: Enabled Inside Hosts:Unlimited Throughput: Unlimited IKE peers: Unlimited This PIX has a Restricted (R) license. Serial Number: 806330010 (0x300f9e9a) Running Activation Key: 0x50c39a05 0x17a94508 0x39b8204a 0x50691aba Configuration last modified by enable_15 at 19:04:14.354 UTC Sun Feb 14 1993 -- show clock -- 19:05:11.235 UTC Sun Feb 14 1993 -- show memory -- Free memory:49178768 bytes Used memory:17930096 bytes - Total memory: 67108864 bytes -- show conn count -- 99 in use, 4993 most used -- show xlate count -- 175 in use, 176 most used -- show blocks -- SIZEMAXLOWCNT 4 1600 1588 1599 80400397400 256 1012912 1011 1550 1189595801 -- show interface -- interface ethernet0 outside is up, line protocol is up Hardware is i82559 ethernet, address is 0090.2799.118f IP address *, subnet mask 255.255.255.0 MTU 1500 bytes, BW 10 Kbit full duplex 393729057 packets input, 3005934690 bytes, 0 no buffer Received 56994 broadcasts, 0 runts, 0 giants 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 368741691 packets output, 3096620746 bytes, 0 underruns 0
[Full-disclosure] Torrential 1.2 getdox.php Directory Traversal
I was poking around my own server because I had an installation of torrential and found this vuln. The problem lies in getdox.php. It works by taking an argument after a /. This specifies a file. The DOX folder that it grabs the files from is located int /dox such that / is the directory that the main index is in. Now, you can give it the parameter of /(any file) and it will fetch that file. EXAMPLES: http://www.example.com/torrential/dox/getdox.php/../forums.php (goes to the forums page) http://www.example.com/torrential/dox/getdox.php/../../index.html (goes to http://www.example.com/index.html in this case) LOCATION FOR DOWNLOAD: prdownloads.sourceforge.net/torrentbits/TBSource_-_Torrential_Beta_1.2-2005-09-25-1220-expert01.rar?download I have already taken preventative measures on my site. ___ 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: Opera Command Line URL Shell Command Injection
== Secunia Research 22/11/2005 - Opera Command Line URL Shell Command Injection - == 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 Opera 8.x on Unix / Linux based environments. Prior versions may also be affected. == 2) Severity Rating: Highly Critical Impact: System access Where: Remote == 3) Description of Vulnerability Secunia Research has discovered a vulnerability in Opera, which can be exploited by malicious people to compromise a user's system. The vulnerability is caused due to the shell script used to launch Opera parsing shell commands that are enclosed within backticks in the URL provided via the command line. This can e.g. be exploited to execute arbitrary shell commands by tricking a user into following a malicious link in an external application which uses Opera as the default browser (e.g. the mail client Evolution on Red Hat Enterprise Linux 4). This vulnerability can only be exploited on Unix / Linux based environments. This vulnerability is a variant of: http://secunia.com/SA16869 == 4) Solution Update to version 8.51. http://www.opera.com/download/ == 5) Time Table 22/09/2005 - Initial vendor notification. 22/09/2005 - Initial vendor reply. 22/11/2005 - Vendor released patches. 22/11/2005 - Public disclosure. == 6) Credits Originally discovered by: Peter Zelezny Discovered in Opera by: Jakob Balle, Secunia Research == 7) References Secunia Advisory SA16869: http://secunia.com/advisories/16869/ == 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-57/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] Re: Your One-Stop Site For Sony Lawsuit Info
That's a great website but it needs to include information about how to contact the Department of Justice so that they will take Sony to court for CRIMINAL action. We need hundreds of thousands of people mailing/emailing/calling the DOJ to get it through their thick skulls that we aren't going to put up with this kind of sh*t from Sony or any other company. Anthony R. Nemmer Larry Seltzer wrote: From some law student http://www.sonysuit.com/ -- SKYKING, SKYKING, DO NOT ANSWER ___ 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] XCP2 v XCP - more than sony at fault?
Hi, I was just reading through the first 4 internet webshite, and i noticed this: - In fact, XCP2 is not as strict as XCP, the company's original product. Sony BMG and the other major labels have been using XCP since 2002 on prerelease CDs sent to radio stations and internal employees, Gilliat-Smith says. XCP not only prevents copying, but in some cases prevents discs from playing in certain devices, he says. Sony chose XCP2, not XCP, for consumer CDs because discs with that encryption play well in most devices. I cannot seem to find any more information on XCP, who the other major labels are I really dont fancy sifting through all the millions of cds we get sent. I am only saying this because one of our radio station PC's got hosed, what are the chances that all those bloody 'sample' cd's have a similar or the same back door. I really hope it is the fat dj downloading goat pr0n. I dont have physical access to the place though. I am trying to get them to send the freshly formatted drive to me for checking. I have contacted First 4 Internet but as yet have received no response (what a surprise). If it is the case that these rootkits have been going to radio stations, the press, etc since 2002 ... there could be some trouble (I help out at a small independent radio station) cause im sure a lot of the big American radio stations have a few pennies ... to sue with Does anyone have any idea about the original XCP software? Cheers Jonny of the Disco ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] [SECURITY] [DSA 900-3] New fetchmail-ssl packages fix potential information leak
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Debian Security Advisory DSA 900-3 [EMAIL PROTECTED] http://www.debian.org/security/ Martin Schulze November 22nd, 2005 http://www.debian.org/security/faq - -- Package: fetchmail Vulnerability : programming error Problem type : local Debian-specific: no CVE ID : CVE-2005-3088 Debian Bug : 336096 Due to restrictive dependency definition for fetchmail-ssl the updated fetchmailconf package couldn't be installed on the old stable distribution (woody) together with fetchmail-ssl. Hence, this update loosens it, so that the update can be pulled in. For completeness we're including the original advisory text: Thomas Wolff discovered that the fetchmailconfig program which is provided as part of fetchmail, an SSL enabled POP3, APOP, IMAP mail gatherer/forwarder, creates the new configuration in an insecure fashion that can lead to leaking passwords for mail accounts to local users. This update also fixes a regression in the package for stable caused by the last security update. For the old stable distribution (woody) this problem has been fixed in version 5.9.11-6.4 of fetchmail and in version 5.9.11-6.3 of fetchmail-ssl. For the stable distribution (sarge) this problem has been fixed in version 6.2.5-12sarge3. For the unstable distribution (sid) this problem has been fixed in version 6.2.5.4-1. We recommend that you upgrade your fetchmail and fetchmail-ssl package. Upgrade Instructions - wget url will fetch the file for you dpkg -i file.deb will install the referenced file. If you are using the apt-get package manager, use the line for sources.list as given below: apt-get update will update the internal database apt-get upgrade will install corrected packages You may use an automated update by adding the resources from the footer to the proper configuration. Debian GNU/Linux 3.0 alias woody - Source archives: http://security.debian.org/pool/updates/main/f/fetchmail-ssl/fetchmail-ssl_5.9.11-6.3.dsc Size/MD5 checksum: 707 3e40bef9e51d8548861b3e0268baaf77 http://security.debian.org/pool/updates/main/f/fetchmail-ssl/fetchmail-ssl_5.9.11-6.3.diff.gz Size/MD5 checksum: 296100 df55a5a18cf5fae859601e2e7fd4b66b http://security.debian.org/pool/updates/main/f/fetchmail-ssl/fetchmail-ssl_5.9.11.orig.tar.gz Size/MD5 checksum: 950273 fff00cbf7be1d01a17605fee23ac96dd Alpha architecture: http://security.debian.org/pool/updates/main/f/fetchmail-ssl/fetchmail-ssl_5.9.11-6.3_alpha.deb Size/MD5 checksum: 309988 b7b2cfaab713c09c23539ba7aa6a54b8 ARM architecture: http://security.debian.org/pool/updates/main/f/fetchmail-ssl/fetchmail-ssl_5.9.11-6.3_arm.deb Size/MD5 checksum: 296688 5e7db6bfdf96674cac7dd77d247bff45 Intel IA-32 architecture: http://security.debian.org/pool/updates/main/f/fetchmail-ssl/fetchmail-ssl_5.9.11-6.3_i386.deb Size/MD5 checksum: 291956 50362e5121557bb590595ceb53a1a603 Intel IA-64 architecture: http://security.debian.org/pool/updates/main/f/fetchmail-ssl/fetchmail-ssl_5.9.11-6.3_ia64.deb Size/MD5 checksum: 333990 01bb01fd63e3c0f9851be135267918a4 HP Precision architecture: http://security.debian.org/pool/updates/main/f/fetchmail-ssl/fetchmail-ssl_5.9.11-6.3_hppa.deb Size/MD5 checksum: 301950 9ea4dfac57fdb8d144f953558ade72c2 Motorola 680x0 architecture: http://security.debian.org/pool/updates/main/f/fetchmail-ssl/fetchmail-ssl_5.9.11-6.3_m68k.deb Size/MD5 checksum: 286422 674343c3868fcf108f24b3564ebc02cf Big endian MIPS architecture: http://security.debian.org/pool/updates/main/f/fetchmail-ssl/fetchmail-ssl_5.9.11-6.3_mips.deb Size/MD5 checksum: 301094 709a4228a19ee982f18f94bb2ae2ac9c Little endian MIPS architecture: http://security.debian.org/pool/updates/main/f/fetchmail-ssl/fetchmail-ssl_5.9.11-6.3_mipsel.deb Size/MD5 checksum: 300582 fe6e85885a472592370519899a06476f PowerPC architecture: http://security.debian.org/pool/updates/main/f/fetchmail-ssl/fetchmail-ssl_5.9.11-6.3_powerpc.deb Size/MD5 checksum: 297546 bfff31d76b66dfc7d43bec54828fb978 IBM S/390 architecture: http://security.debian.org/pool/updates/main/f/fetchmail-ssl/fetchmail-ssl_5.9.11-6.3_s390.deb Size/MD5 checksum: 294632 5ab160cc2d2df011efacc0d6668d2a0f Sun Sparc architecture: http://security.debian.org/pool/updates/main/f/fetchmail-ssl/fetchmail-ssl_5.9.11-6.3_sparc.deb Size/MD5 checksum: 298246 8ff9bca8d4dcc6242bbc2cfe8c16ddfa These files will probably be moved into the stable distribution on its next update. -
Re: [Full-disclosure] XCP2 v XCP - more than sony at fault?
On 11/22/05, Michael Holstein [EMAIL PROTECTED] wrote: If it is the case that these rootkits have been going to radio stations, the press, etc since 2002 ... there could be some trouble (I help out at a small independent radio station) cause im sure a lot of the big American radio stations have a few pennies ... to sue with Most of the big stations use the music digitally in the first place (under license .. and usually under 'pay for play' agreements). These days, anyone that puts *any* CD in their computer and lets it autorun is really asking for it. I hope Microsoft disables autoplay with an update in the future -- that would stop this silliness dead in its tracks. ~Mike. Running a restricted user account by default would also help (no admin privileges given to the application located on the CD). I recommend everyone to get into this habit when using Windows desktops. In cases in which you need admin privileges to install an application you can just use the command run as by right-clicking on the executable to install. ___ 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] XCP2 v XCP - more than sony at fault?
Running a restricted user account by default would also help (no admin privileges given to the application located on the CD). I recommend everyone to get into this habit when using Windows desktops. In cases in which you need admin privileges to install an application you can just use the command run as by right-clicking on the executable to install. Ditto to all of this. It's not just good practice, it specifically stops the XCP software which reports that it (actually, it says that the music player) requires administrator privileges to install. I'm sure most people would just login as admin and install, but at least at that point you're explicitly pointing the gun at your own head and pulling the trigger. Larry Seltzer eWEEK.com Security Center Editor http://security.eweek.com/ http://blog.ziffdavis.com/seltzer Contributing Editor, PC Magazine [EMAIL PROTECTED] ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] [ GLSA 200511-17 ] FUSE: mtab corruption through fusermount
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Gentoo Linux Security Advisory GLSA 200511-17 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - http://security.gentoo.org/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Severity: Normal Title: FUSE: mtab corruption through fusermount Date: November 22, 2005 Bugs: #112902 ID: 200511-17 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Synopsis The fusermount utility from FUSE can be abused to corrupt the /etc/mtab file contents, potentially allowing a local attacker to set unauthorized mount options. Background == FUSE (Filesystem in Userspace) allows implementation of a fully functional filesystem in a userspace program. The fusermount utility is used to mount/unmount FUSE file systems. Affected packages = --- Package / Vulnerable / Unaffected --- 1 sys-fs/fuse 2.4.1-r1= 2.4.1-r1 Description === Thomas Biege discovered that fusermount fails to securely handle special characters specified in mount points. Impact == A local attacker could corrupt the contents of the /etc/mtab file by mounting over a maliciously-named directory using fusermount, potentially allowing the attacker to set unauthorized mount options. This is possible only if fusermount is installed setuid root, which is the default in Gentoo. Workaround == There is no known workaround at this time. Resolution == All FUSE users should upgrade to the latest version: # emerge --sync # emerge --ask --oneshot --verbose =sys-fs/fuse-2.4.1-r1 References == [ 1 ] CVE-2005-3531 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3531 Availability This GLSA and any updates to it are available for viewing at the Gentoo Security Website: http://security.gentoo.org/glsa/glsa-200511-17.xml Concerns? = Security is a primary focus of Gentoo Linux and ensuring the confidentiality and security of our users machines is of utmost importance to us. Any security concerns should be addressed to [EMAIL PROTECTED] or alternatively, you may file a bug at http://bugs.gentoo.org. License === Copyright 2005 Gentoo Foundation, Inc; referenced text belongs to its owner(s). The contents of this document are licensed under the Creative Commons - Attribution / Share Alike license. http://creativecommons.org/licenses/by-sa/2.0 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] Cisco PIX TCP Connection Prevention
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Cisco Response == This is Cisco PSIRT's response to the statements made by Arhont Ltd.- Information Security in its message: [Full-disclosure] Cisco PIX TCP Connection Prevention, posted on November 22, 2005. The original email is available at: http://lists.grok.org.uk/pipermail/full-disclosure/2005-November/038971. html This issue is being tracked by two Cisco Bug IDs: * CSCsc14915 -- PIX 6.3 Spoofed TCP SYN packets can block legitimate TCP connections This Bug ID tracks the issue for PIX software version 6.3 and older. This DDTS is under investigation and while not resolved there are workarounds available to mitigate the issue. * CSCsc16014 -- PIX 7.0 Spoofed TCP SYN packets can block legitimate TCP connections This Bug ID tracks the issue for PIX/ASA software version 7.0. This DDTS is under investigation and while not resolved additional mitigations and workarounds exist to limit or eliminate the issue. We would like to thank Arhont Ltd.- Information Security for reporting this issue to us. We greatly appreciate the opportunity to work with researchers on security vulnerabilities, and welcome the opportunity to review and assist in product reports. Additional Information == PIX 6.3 === * CSCsc14915 -- PIX 6.3 Spoofed TCP SYN packets can block legitimate TCP connections This issue affects PIX software version 6.3 and older. The Release Note Enclosure for this Bug ID states: Symptom +-- TCP connections through the firewall may be silently blocked. Conditions +- By sending a TCP SYN packet with an incorrect checksum through a PIX firewall, the PIX will block new TCP connections using the same source and destination TCP ports and IP addresses. Connections will remain blocked for approximately two minutes after which connections will be allowed. This behavior may be seen on all firewall interfaces but can be expected to have the most impact on TCP connections originating from higher security level interfaces to lower security level interfaces. Since the spoofed packets have an incorrect checksum, they are silently discarded by the destination and the firewall will not see a RST packet from either the destination or the legitimate source and will hold the embryonic connection open until the embryonic connection timeout which is 2 minutes by default. The root cause is due to the spoofed packet creating an embryonic connection which sets up the TCP sliding window. A valid packet from a real host using the same connection as the spoofed packet sends a SYN over the same connection. The sequence number of the valid packet is out-of-window and rejected by the firewall's TCP sequence number check. Any subsequent retransmissions of the valid packet are also out-of-window and are rejected by TCP sequence number check. Other spoofed TCP SYN packets that create embryonic connections can also cause this behavior, blocking legitimate TCP connections until the embryonic connection times out. Workarounds +-- Issuing the commands clear xlate or clear local-host ip address on the higher security level interface will allow the firewall to pass connections again. TCP connections discarded because of this issue can be verified by enabling debug fixup tcp. 'Out of Window' drops will then generate messages that begin with tcpseq: discard old packet. Debug messages may impact firewall performance and should be tested before being enabled in a production environment. For discarded TCP connections originating from lower security level interfaces to higher security level interfaces, TCP Intercept can be configured on STATIC commands by setting the emb_limit to 1. This results in the PIX proxying all connection attempts after the first connection. The PIX will create and send the TCP SYN,ACK from the destination to the original source. Since the original TCP SYN packet was spoofed, the source IP address will not be tracking the TCP connection and it will send a TCP RST to the PIX. The PIX will then close the connection originating from the TCP SYN packet with the incorrect checksum. TCP Intercept may impact firewall performance and should be tested before being enabled in a production environment. Further Problem Description +-- PIX software version 6.3 does not verify the TCP checksum of packets transiting through the firewall. Because the PIX does not verify the TCP checksum, the malformed TCP packet is allowed through the firewall in a half-opened, embryonic state. The destination host discards the received malformed segments. Because the firewall does not see a return segment from the destination host it holds the half-open TCP connection open until the embryonic timeout which is set to two minutes for PIX 6.3 and earlier software. Because the firewall is holding a
[Full-disclosure] Cisco PIX TCP Connection Prevention
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Cisco Response == This is Cisco PSIRT's response to the statements made by Arhont Ltd.- Information Security in its message: [Full-disclosure] Cisco PIX TCP Connection Prevention, posted on November 22, 2005. The original email is available at: http://lists.grok.org.uk/pipermail/full-disclosure/2005-November/038971. html Attached is a cleartext, PGP signed version of this same email. This issue is being tracked by two Cisco Bug IDs: * CSCsc14915 -- PIX 6.3 Spoofed TCP SYN packets can block legitimate TCP connections This Bug ID tracks the issue for PIX software version 6.3 and older. This DDTS is under investigation and while not resolved there are workarounds available to mitigate the issue. * CSCsc16014 -- PIX 7.0 Spoofed TCP SYN packets can block legitimate TCP connections This Bug ID tracks the issue for PIX/ASA software version 7.0. This DDTS is under investigation and while not resolved additional mitigations and workarounds exist to limit or eliminate the issue. We would like to thank Arhont Ltd.- Information Security for reporting this issue to us. We greatly appreciate the opportunity to work with researchers on security vulnerabilities, and welcome the opportunity to review and assist in product reports. Additional Information == PIX 6.3 === * CSCsc14915 -- PIX 6.3 Spoofed TCP SYN packets can block legitimate TCP connections This issue affects PIX software version 6.3 and older. The Release Note Enclosure for this Bug ID states: Symptom +-- TCP connections through the firewall may be silently blocked. Conditions +- By sending a TCP SYN packet with an incorrect checksum through a PIX firewall, the PIX will block new TCP connections using the same source and destination TCP ports and IP addresses. Connections will remain blocked for approximately two minutes after which connections will be allowed. This behavior may be seen on all firewall interfaces but can be expected to have the most impact on TCP connections originating from higher security level interfaces to lower security level interfaces. Since the spoofed packets have an incorrect checksum, they are silently discarded by the destination and the firewall will not see a RST packet from either the destination or the legitimate source and will hold the embryonic connection open until the embryonic connection timeout which is 2 minutes by default. The root cause is due to the spoofed packet creating an embryonic connection which sets up the TCP sliding window. A valid packet from a real host using the same connection as the spoofed packet sends a SYN over the same connection. The sequence number of the valid packet is out-of-window and rejected by the firewall's TCP sequence number check. Any subsequent retransmissions of the valid packet are also out-of-window and are rejected by TCP sequence number check. Other spoofed TCP SYN packets that create embryonic connections can also cause this behavior, blocking legitimate TCP connections until the embryonic connection times out. Workarounds +-- Issuing the commands clear xlate or clear local-host ip address on the higher security level interface will allow the firewall to pass connections again. TCP connections discarded because of this issue can be verified by enabling debug fixup tcp. 'Out of Window' drops will then generate messages that begin with tcpseq: discard old packet. Debug messages may impact firewall performance and should be tested before being enabled in a production environment. For discarded TCP connections originating from lower security level interfaces to higher security level interfaces, TCP Intercept can be configured on STATIC commands by setting the emb_limit to 1. This results in the PIX proxying all connection attempts after the first connection. The PIX will create and send the TCP SYN,ACK from the destination to the original source. Since the original TCP SYN packet was spoofed, the source IP address will not be tracking the TCP connection and it will send a TCP RST to the PIX. The PIX will then close the connection originating from the TCP SYN packet with the incorrect checksum. TCP Intercept may impact firewall performance and should be tested before being enabled in a production environment. Further Problem Description +-- PIX software version 6.3 does not verify the TCP checksum of packets transiting through the firewall. Because the PIX does not verify the TCP checksum, the malformed TCP packet is allowed through the firewall in a half-opened, embryonic state. The destination host discards the received malformed segments. Because the firewall does not see a return segment from the destination host it holds the half-open TCP connection open until the embryonic timeout which is set to two minutes for PIX
[Full-disclosure] [SECURITY] [DSA 906-1] New sylpheed packages fix arbitrary code execution
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Debian Security Advisory DSA 906-1 [EMAIL PROTECTED] http://www.debian.org/security/ Martin Schulze November 22nd, 2005 http://www.debian.org/security/faq - -- Package: sylpheed Vulnerability : buffer overflows Problem type : remote Debian-specific: no CVE ID : CVE-2005-3354 Debian Bug : 338436 Colin Leroy discovered several buffer overflows in a number of importer routines in sylpheed, a light-weight e-mail client with GTK+, that could lead to the execution of arbitrary code. The following matrix explains which versions fix this vulnerability old stable (woody) stable (sarge) unstable (sid) sylpheed 0.7.4-4woody1 1.0.4-1sarge1 2.0.4-1 sylpheed-gtk1 n/a n/a 1.0.6-1 sylpheed-claws 0.7.4claws-3woody1 1.0.4-1sarge1 1.0.5-2 sylpheed-claws-gtk2n/a n/a 1.9.100-1 We recommend that you upgrade your sylpheed package. Upgrade Instructions - wget url will fetch the file for you dpkg -i file.deb will install the referenced file. If you are using the apt-get package manager, use the line for sources.list as given below: apt-get update will update the internal database apt-get upgrade will install corrected packages You may use an automated update by adding the resources from the footer to the proper configuration. Debian GNU/Linux 3.0 alias woody - Source archives: http://security.debian.org/pool/updates/main/s/sylpheed/sylpheed_0.7.4-4woody1.dsc Size/MD5 checksum: 809 e2347bf6ce11e212ab44b5a7de555b07 http://security.debian.org/pool/updates/main/s/sylpheed/sylpheed_0.7.4-4woody1.diff.gz Size/MD5 checksum: 1460259 d22f631c079bd96fc720b41046590ae6 http://security.debian.org/pool/updates/main/s/sylpheed/sylpheed_0.7.4.orig.tar.gz Size/MD5 checksum: 2392658 4f35c4925a9c9678b70f275a898a4a6b Architecture independent components: http://security.debian.org/pool/updates/main/s/sylpheed/sylpheed-doc_0.7.4-4woody1_all.deb Size/MD5 checksum: 1418744 55e42c4f703fdc2464126247b5b299a7 Alpha architecture: http://security.debian.org/pool/updates/main/s/sylpheed/sylpheed_0.7.4-4woody1_alpha.deb Size/MD5 checksum: 1284984 922289db3e1f15c360c3a98ea4411d0b ARM architecture: http://security.debian.org/pool/updates/main/s/sylpheed/sylpheed_0.7.4-4woody1_arm.deb Size/MD5 checksum: 1191522 9450fd7553a16e73d8896a44bca0097b Intel IA-32 architecture: http://security.debian.org/pool/updates/main/s/sylpheed/sylpheed_0.7.4-4woody1_i386.deb Size/MD5 checksum: 1174296 6ba9efd2654c18615bd8b64a07d28094 Intel IA-64 architecture: http://security.debian.org/pool/updates/main/s/sylpheed/sylpheed_0.7.4-4woody1_ia64.deb Size/MD5 checksum: 1441450 245fb9dd7fdb9e4ed0eff7b12853b5bf HP Precision architecture: http://security.debian.org/pool/updates/main/s/sylpheed/sylpheed_0.7.4-4woody1_hppa.deb Size/MD5 checksum: 1277040 47c8af49ea30b9a7d6fa354fd64ec7d4 Motorola 680x0 architecture: http://security.debian.org/pool/updates/main/s/sylpheed/sylpheed_0.7.4-4woody1_m68k.deb Size/MD5 checksum: 1143172 b1296dd212303acea573c3a8c78ec1fc Big endian MIPS architecture: http://security.debian.org/pool/updates/main/s/sylpheed/sylpheed_0.7.4-4woody1_mips.deb Size/MD5 checksum: 1201778 03c3fdeee83a534b7d84a4737e33f86d Little endian MIPS architecture: http://security.debian.org/pool/updates/main/s/sylpheed/sylpheed_0.7.4-4woody1_mipsel.deb Size/MD5 checksum: 1197450 6c095c451e04637b1e29c29d68d6e4e3 PowerPC architecture: http://security.debian.org/pool/updates/main/s/sylpheed/sylpheed_0.7.4-4woody1_powerpc.deb Size/MD5 checksum: 1196634 925bdab51d9f24e6d75f83a98fee4cc2 IBM S/390 architecture: http://security.debian.org/pool/updates/main/s/sylpheed/sylpheed_0.7.4-4woody1_s390.deb Size/MD5 checksum: 1174614 ec34f80d0a3545528bc358d8ffd3b77f Sun Sparc architecture: http://security.debian.org/pool/updates/main/s/sylpheed/sylpheed_0.7.4-4woody1_sparc.deb Size/MD5 checksum: 1187816 d59bcdb7ca66390b1bb01a540bb935f4 Debian GNU/Linux 3.1 alias sarge - Source archives: http://security.debian.org/pool/updates/main/s/sylpheed/sylpheed_1.0.4-1sarge1.dsc Size/MD5 checksum: 948 6b57fc4b878f1c8d0ddcccaf15813ff1 http://security.debian.org/pool/updates/main/s/sylpheed/sylpheed_1.0.4-1sarge1.diff.gz Size/MD5 checksum:16171 91e577bed02a58ac10f85e1ec4e859c2
Re: [Full-disclosure] Re: Your One-Stop Site For Sony Lawsuit Info
Anthony R. Nemmer wrote: That's a great website but it needs to include information about how to contact the Department of Justice so that they will take Sony to court for CRIMINAL action. We need hundreds of thousands of people mailing/emailing/calling the DOJ to get it through their thick skulls that we aren't going to put up with this kind of sh*t from Sony or any other company. Unfortunately, the end result of a criminal conviction for a corporation is nothing more than a fine. You can't put a corporation in prison, and there's no corporate death penalty. The only option available to the people is mob justice. Corporations can be ruined and they can be burned to the ground, but they can't be touched in a meaningful way through mechanisms of law. Corporate persons are truly first-class citizens, rising above the rest of us natural persons in importance and worth to society. Regards, 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: Your One-Stop Site For Sony Lawsuit Info
--On Tuesday, November 22, 2005 07:47:29 -1000 Jason Coombs [EMAIL PROTECTED] wrote: Anthony R. Nemmer wrote: That's a great website but it needs to include information about how to contact the Department of Justice so that they will take Sony to court for CRIMINAL action. We need hundreds of thousands of people mailing/emailing/calling the DOJ to get it through their thick skulls that we aren't going to put up with this kind of sh*t from Sony or any other company. Unfortunately, the end result of a criminal conviction for a corporation is nothing more than a fine. You can't put a corporation in prison, and there's no corporate death penalty. The only option available to the people is mob justice. Corporations can be ruined and they can be burned to the ground, but they can't be touched in a meaningful way through mechanisms of law. Corporate persons are truly first-class citizens, rising above the rest of us natural persons in importance and worth to society. So, all those corporate execs walked out of the court house in handcuffs weren't really going to jail? Paul Schmehl ([EMAIL PROTECTED]) Adjunct Information Security Officer University of Texas at Dallas AVIEN Founding Member http://www.utdallas.edu/ir/security/ ___ 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: Google Base
Petko Petkov wrote: Hi Alexander, You are right! Free hosting, free email, tag based systems exist for quite a while and they can be used for the exact same purposes that I mentioned in my original post. Common, everybody knows how to configure DNS to serve hashes (sort of distributed rainbow tables crack). However, google base it a bit different. First of all Google has enormous storage facilities. You need around 85g for a decent rainbow table. I don't think that I you can find that for free. Yes, maybe, Google Base is not that well suited for this kind of stuff but, still. It seems items will expire in 31 days. I don't think it's well suited for rainbow databases at all. Jorrit ___ 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: Your One-Stop Site For Sony Lawsuit Info
Paul Schmehl wrote: So, all those corporate execs walked out of the court house in handcuffs weren't really going to jail? There's a huge difference between a financial crime committed by an individual and a crime committed by a corporation. Let me know if the distinction confuses you and we'll discuss this more privately. You are aware that not every action of a person employed by a corporation is considered an action of the individual, right? No individual programmer who writes spyware will ever be prosecuted for doing his or her job on behalf of a corporation. No exec who instructs said programmer to author said spyware will ever have personal criminal liability for giving said instruction. If you don't like the world you live in, change it or get out. Regards, 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: Your One-Stop Site For Sony Lawsuit Info
Hi Jason, Paul: While Jason's point may _currently_ be valid in reference to programmers, legislation like Sarbanes-Oxley is reiterating individual accountability for auditors and executives. We may see a trickle-down effect to lower level management and/or project managers if other corporations infringe on personal liberties or pull a Sony. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Coombs Sent: Tuesday, November 22, 2005 12:13 PM To: Paul Schmehl Cc: [EMAIL PROTECTED]; bugtraq@securityfocus.com; full-disclosure@lists.grok.org.uk Subject: Re: [Full-disclosure] Re: Your One-Stop Site For Sony Lawsuit Info Paul Schmehl wrote: So, all those corporate execs walked out of the court house in handcuffs weren't really going to jail? There's a huge difference between a financial crime committed by an individual and a crime committed by a corporation. Let me know if the distinction confuses you and we'll discuss this more privately. You are aware that not every action of a person employed by a corporation is considered an action of the individual, right? No individual programmer who writes spyware will ever be prosecuted for doing his or her job on behalf of a corporation. No exec who instructs said programmer to author said spyware will ever have personal criminal liability for giving said instruction. If you don't like the world you live in, change it or get out. Regards, 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 - 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] XCP2 v XCP - more than sony at fault?
Larry Seltzer wrote: Running a restricted user account by default would also help (no admin privileges given to the application located on the CD). I recommend everyone to get into this habit when using Windows desktops. In cases in which you need admin privileges to install an application you can just use the command run as by right-clicking on the executable to install. Ditto to all of this. It's not just good practice, it specifically stops the XCP software which reports that it (actually, it says that the music player) requires administrator privileges to install. I'm sure most people would just login as admin and install, but at least at that point you're explicitly pointing the gun at your own head and pulling the trigger. I agree with the general points about using non-privileged users and as well for disabling auto-run. However, I think that you made the right point by saying that most people would just login as admin and install, but I think that this thinking may represent a problem for the information technology industry and security. The problem, of course, is normal users. Yes, security professionals have gotten hit with this. But most security professionals are pretty savvy when it comes to operating their PCs. For the most part, I'm not too concerned with what we do. And we're the only ones who will actually, unfortunately, be helped by these suggestions. Most normal users will still double-click on the CD to execute the content. Most normal users will still happily run as admin in order to execute the installer. Trust is the issue in this situation. People trusted Sony, and Sony violated that trust. Unfortunately, there are no easy solutions. As long as people are allowed to execute random code on their own computers, trust will continue to trip people up. I'm not sure that there is an easy answer to this. But those of us who are security savvy should begin thinking about what our answers will do for the average user. The advice given here is a step in the right direction, but I don't personally believe that it will end the flood of malware and the like out there. I think that the people cracking systems and installing crap like XCP are going to continue doing it, knowing full well that trust is their ally. So what is the solution? I don't know really... it's a tough nut to crack. Education works well, but what do we say in this case? Say Trust no one because large corporations will screw you as badly as everyone else? Thanks Sony - you really made our jobs easier here. /sarcasm And what about the vaunted end goal of hardware-based DRM? Restriction of what can be installed on a person's system. I'm not comfortable with that either... first of all because we all know that it won't take people long to find a way around it and those people illegally distributing malware could care less about violating the DMCA. Second of all because something like that won't stop companies from installing crap like XCP. And third of all because it reduces the ability for people to control their own environments, making crap like XCP harder for people to remove (which is a wholesale loss for the consumer). So what's the permanent fix here? I don't know... I think I, as well as everyone else, am open to new ideas. I think that we, as an industry, need to very seriously think about what the safest method of installing and auditing new code is. The best thing I can think of at the moment is an OS-defined new-code sandbox that can't access anything else until approved... but that's only a start, and is still somewhat subjected to the trust factor. -bkfsec ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Re: Your One-Stop Site For Sony Lawsuit Info
IANAL, but here with respect to German law: On Tue, 22 Nov 2005 09:13:26 -1000 Jason Coombs [EMAIL PROTECTED] wrote: Paul Schmehl wrote: So, all those corporate execs walked out of the court house in handcuffs weren't really going to jail? Let me know if the distinction confuses you and we'll discuss this more privately. You are aware that not every action of a person employed by a corporation is considered an action of the individual, right? Wrong. It always includes personal responsibility (to a greater or lesser degree, depending on what exactly happened). If an accident or mishap happens during regular (legal!) work, it usually is on the liability of the corporation (as that is the usual risk of running an enterprise). No individual programmer who writes spyware will ever be prosecuted for doing his or her job on behalf of a corporation. At least he will get prosecuted for complicity, probably addidtionally for not reporting a crime, witholding evidence et al., too. No exec who instructs said programmer to author said spyware will ever have personal criminal liability for giving said instruction. He will - for instigation, complicity and additionally blackmailing a subordinate or ward (if the programmer's attorney is not too dumb). Maybe that personal responsibility is a late sequel to the lame Nazi excuse I did not commit a crime - I was just following Hitler's orders. here in Germany, so it might not be as strict in the USA? Bye Volker -- Volker Tangerhttp://www.wyae.de/volker.tanger/ -- [EMAIL PROTECTED]PGP Fingerprint 378A 7DA7 4F20 C2F3 5BCC 8340 7424 6122 BB83 B8CB ___ 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] Hacking Boot camps!
Hmm, there was hands on hacking, but by the company that sold you the training, it sounds like you got owned by salesman.c. Blackhat training camps sound pretty good and some of the people are pretty damn skilled, but these others Zone-H, Vigilante and the likes I would avoid. blind leading the blind if you ask me. I'd research who your mentors were before even thinking about signing, On 22/11/05, K Tucker [EMAIL PROTECTED] wrote: Seems that I read from time to time people asking about the merits of these hacker boot camps. It might be helpful if I relate my recent experience. I attended a 5 day Hacker boot camp conducted by Intense school which is part of Vigilar. Cost was $3200, which I paid out of my own pocket. The salesman I spoke with did a great job selling me on the idea of how hands on it was going to be and all the tools the instructor was going to show us how to use. The classes were supposed to be from 8:30am to 6:00pm for the 5 days. The instructor didn't show up until 4:00 pm due to scheduling conflict. We only received 3 hours that day. The following days started at 9:00 not 8:30 as advertised which might seem like a small thing but at $3200 every minute counts! The real disappointment was the quality of the class. There was little actual lab work. 90% of the class was sitting while the instructor read from the class manual while we looked at a slide of the same page he was reading. Sure it was nice to be read things like CAIN and ABEL is a good program for sniffing networks, but we in the class wanted to know how do you use it! We were never shown. We did have a little hands on lab work which involved ethereal and sam spade and netcat. It was hard to get them to work because none of our vmware was connected to the network correctly so we wasted another hour just trying to get that to work! The feeling in the class was that the class computers should have been set up and ready to go before we even arrived. Friday was the big disappointment. The class began at 9:00am and they started the CEH examine at 11:00 am. That test only lasts 3 hours so by 2:00pm the school was over! Most of the class did not take the test because we didn't feel ready. 5 people in the class did take it and 2 passed it. Those 2 were very experienced in network security. The other 3 failed it. I have emailed Intense school 4 times with my concerns but have never heard back from them. I guess they are not too concerned. My feeling is someone would do much better to just get the book Hacking Exposed and download the suggested tools and play with them. You will learn much more and save a lot of money! __ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.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/ -- regards c0ntex ___ 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] Hacking Boot camps!
Sounds like Intense school hacked you out of $3200. That's known as social engineering (I'm sure that chapter is in the book). Nobody's going to be ub3r l33t in 5 days - despite what Intense's glossy lit suggests to the contrary. Nor will they get you a CISE, MCSE, or whatever other lettered credential you seek (in only 5 days). Download Knoppix-std and sit at Starbucks on a Sunday afternoon and practice ;) ~Mike. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Hacking Boot camps!
This line cracked me up, um...maybe you missed that chapter in the book there son. Sounds like Intense school hacked you out of $3200. That's known as social engineering (I'm sure that chapter is in the book). When will wanna-be security folk learn, you have to do the work on your own to really understand it. Scott Renna CISSP GIAC Gold: GCIA, GCIH Security Team Lead ___ 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: Your One-Stop Site For Sony Lawsuit Info
Not just SOX. HIPAA and GLB will do the same thing. HIPAA will hold an individual practioner liable for security failures, if the corp had an acceptable plan but the implementation either never took place or was done shoddily. If the plan isn't in place, then the admins are liable - personally liable. --On Tuesday, November 22, 2005 12:20:33 -0700 Christopher Carpenter [EMAIL PROTECTED] wrote: Hi Jason, Paul: While Jason's point may _currently_ be valid in reference to programmers, legislation like Sarbanes-Oxley is reiterating individual accountability for auditors and executives. We may see a trickle-down effect to lower level management and/or project managers if other corporations infringe on personal liberties or pull a Sony. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Coombs Sent: Tuesday, November 22, 2005 12:13 PM To: Paul Schmehl Cc: [EMAIL PROTECTED]; bugtraq@securityfocus.com; full-disclosure@lists.grok.org.uk Subject: Re: [Full-disclosure] Re: Your One-Stop Site For Sony Lawsuit Info Paul Schmehl wrote: So, all those corporate execs walked out of the court house in handcuffs weren't really going to jail? There's a huge difference between a financial crime committed by an individual and a crime committed by a corporation. Let me know if the distinction confuses you and we'll discuss this more privately. You are aware that not every action of a person employed by a corporation is considered an action of the individual, right? No individual programmer who writes spyware will ever be prosecuted for doing his or her job on behalf of a corporation. No exec who instructs said programmer to author said spyware will ever have personal criminal liability for giving said instruction. If you don't like the world you live in, change it or get out. Regards, 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/ Paul Schmehl ([EMAIL PROTECTED]) Adjunct Information Security Officer University of Texas at Dallas AVIEN Founding Member http://www.utdallas.edu/ir/security/ ___ 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] Hacking Boot camps!
Interesting about the Intense thing... ( sory for your loss ) Blackhat training camps sound pretty good and some of the people are pretty damn skilled, but these others Zone-H, Vigilante and the likes I would avoid. blind leading the blind if you ask me. I dont know about the others, but i do know Zone-h Hands on Hacking 2 day seminars are worth it, have actual hands on hacking labs, and are quite informative. ( and dont claim to be blackhat style training, nor a CEH prep class) While not targeted for the security professional, they are an exelent way for lower level admins, developers, corporate IT, and others that are not security savy to learn about real-world attacks and mitigation. mw ___ 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] Hacking Boot camps!
Oh MW, what do you know about Zone-H? lol It isn't like you have anything to do with that stuff...oh..wait...lol -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Morning Wood Sent: Monday, November 21, 2005 3:09 PM To: full-disclosure@lists.grok.org.uk Subject: Re: [Full-disclosure] Hacking Boot camps! Interesting about the Intense thing... ( sory for your loss ) Blackhat training camps sound pretty good and some of the people are pretty damn skilled, but these others Zone-H, Vigilante and the likes I would avoid. blind leading the blind if you ask me. I dont know about the others, but i do know Zone-h Hands on Hacking 2 day seminars are worth it, have actual hands on hacking labs, and are quite informative. ( and dont claim to be blackhat style training, nor a CEH prep class) While not targeted for the security professional, they are an exelent way for lower level admins, developers, corporate IT, and others that are not security savy to learn about real-world attacks and mitigation. mw ___ 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] OTRS 1.x/2.x Multiple Security Issues
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
SA0007
+
+ OTRS 1.x/2.x Multiple Security Issues +
+
PUBLISHED ON
Nov 22, 2005
PUBLISHED AT
http://moritz-naumann.com/adv/0007/otrsmulti/0007.txt
http://moritz-naumann.com/adv/0007/otrsmulti/0007.txt.sig
PUBLISHED BY
Moritz Naumann IT Consulting Services
Hamburg, Germany
http://moritz-naumann.com/
SECURITY at MORITZ hyphon NAUMANN d0t COM
GPG key: http://moritz-naumann.com/keys/0x277F060C.asc
AFFECTED APPLICATION OR SERVICE
OTRS
http://www.otrs.org/
OTRS, the Open Source Ticket Request System, is a trouble
ticket system which allows for managing customer telephone
calls and e-mails.
AFFECTED VERSIONS
Version 2.0.0 up to and including 2.0.3 and OTRS 1.0.0 up
to and including 1.3.2.
ISSUES
OTRS is subject to multiple security vulnerabilities,
ranging from cross site scripting to SQL injection.
1. SQL injection #1
A malicious user may be able to conduct blind SQL code
injection on the OTRS 'Login' function. Successful
authentication is NOT required. By injecting a LEFT JOIN
statement into the authentication database SQL query,
an attacker may be able to exploit this issue.
The following partial URL demonstrates this issue:
[OTRS_BaseURI]/index.pl?Action=LoginUser=%27[SQL_HERE]
This results in an SQL error message being logged in the
OTRS system log.
2. SQL injection #2
A malicious user may be able to conduct blind SQL code
injection on the OTRS 'AgentTicketPlain' function in the
'TicketID' parameter. Successful authentication IS required,
however, a non-authenticated user will be prompted for her
login credentials and the attack will still be carried out
after the login succeeded. By injecting a LEFT JOIN statement
into the SQL query, an attacker may be able to exploit this
issue.
The following partial URL demonstrates this issue:
[OTRS_BaseURI]/admin/index.pl?Action=AgentTicketPlainArticleID=1TicketID=1%20[SQL_HERE]
This results in an SQL error message being logged in the
OTRS system log.
3. SQL injection #3
A malicious user may be able to conduct blind SQL code
injection on the OTRS 'AgentTicketPlain' function in the
'ArticleID' parameter. Successful authentication IS required,
however, a non-authenticated user will be prompted for her
login credentials and the attack will still be carried out
after the login succeeded. By injecting a LEFT JOIN statement
into the SQL query, an attacker may be able to exploit this
issue.
The following partial URL demonstrates this issue:
[OTRS_BaseURI]/admin/index.pl?Action=AgentTicketPlainTicketID=1ArticleID=1%20[SQL_HERE]
This results in an SQL error message being logged in the
OTRS system log.
4. Cross Site Scripting #1
OTRS is subject to a XSS vulnerability on the file attachment
display function.
An attacker may send malicious code inside an email attachment
of Content-Type text/html. A queue moderator clicking the
attachment download button (disk symbol) on a ticket created
based on a HTML email will have this attachment rendered by
her browser. Thus, any malicious client side code included in
the HTML attachment will be executed in the security context
of the OTRS domain.
This refers to the default configuration
(AttachmentDownloadType = inline) but does not apply if
AttachmentDownloadType is set to attachment.
5. Cross Site Scripting #2
OTRS is subject to a XSS vulnerability on the queue selection
function.
An attacker may inject arbitrary client side script code into
the 'QueueID' parameter. Successful authentication IS required,
however, a non-authenticated user will be prompted for her
login credentials and the attack will still be carried out
after the login succeeded.
The following partial URL demonstrates this issue:
[OTRS_BaseURI]/index.pl?QueueID=%22%3E%3Cscript%3Ealert('[XSS_HERE]')%3B%3C/script%3E%3Cx%20y=%22
6. Cross Site Scripting #3
OTRS is subject to a XSS vulnerability on the 'Action'
parameter. An attacker may inject arbitrary client side script
code into this parameter. To exploit this issue, successful
authentication IS required, however, a non-authenticated user
will be prompted for her login credentials and the attack will
still be carried out after the login succeeded.
The following partial URL demonstrates this issue:
[OTRS_BaseURI]/index.pl?Action=scriptalert(document.title);/scriptx%20
This is only exploitable on web browsers which perform limited
URL encoding before submitting user input, such as Internet
Explorer (tested on v6.2900.2180 including all patches on
Windows XP SP2) and Konqueror (tested on V3.3.2).
BACKGROUND
SQL Injection:
SQL injection describes the inclusion of additional SQL
database query language statements into an
[Full-disclosure] PmWiki 2.0.12 Cross Site Scripting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 SA0005 + +PmWiki 2.0.12 Cross Site Scripting + + PUBLISHED ON Nov 22, 2005 PUBLISHED AT http://moritz-naumann.com/adv/0005/pmwiki/0005.txt http://moritz-naumann.com/adv/0005/pmwiki/0005.txt.sig PUBLISHED BY Moritz Naumann IT Consulting Services Hamburg, Germany http://moritz-naumann.com/ SECURITY at MORITZ hyphon NAUMANN d0t COM GPG key: http://moritz-naumann.com/keys/0x277F060C.asc AFFECTED APPLICATION OR SERVICE PmWiki http://www.pmwiki.org/ AFFECTED VERSION Version 2.0 up to and including 2.0.12 BACKGROUND Everybody knows XSS. http://en.wikipedia.org/wiki/XSS http://www.cgisecurity.net/articles/xss-faq.shtml ISSUE PmWiki 2.0.12 is subject to a XSS vulnerability. The problem exists in the 'q' parameter passed to the search function. Successful exploitation may allow for impersonification through session stealing. The following URL demonstrates this issue: [pmwiki_basedir]/Site/Search?action=searchq=TRY%20ANOTHER%20SEARCH%20NOW!%20YES,%20YOU!'%20onMouseOver='alert(document.title);'%20 This issue is caused by insufficient input validation. WORKAROUND Client: Disable Javascript. Server: Prevent access to pagelist.php. SOLUTIONS Install or upgrade to the latest release, version 2.0.13. Both releases and patch files are available at http://www.pmwiki.org/pub/pmwiki/ TIMELINE Nov 05, 2005 Discovery Nov 05, 2005 Code maintainer notified Nov 09, 2005 Code maintainer replies Nov 10, 2005 Code maintainer provides fix Nov 11, 2005 CVE candidate assignment requested Nov 22, 2005 Sick of waiting for Mitre to fix their DB Nov 22, 2005 Public disclosure REFERENCES N/A ADDITIONAL CREDIT N/A LICENSE Creative Commons Attribution-ShareAlike License Germany http://creativecommons.org/licenses/by-sa/2.0/de/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDg45kn6GkvSd/BgwRAgeGAJ90QWc8Se621Y1wAtywgPZGgMFz2wCdFt4R r/WQ/+HbTQq5wyDakQDRAr8= =hRgJ -END PGP SIGNATURE- ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Re: Google Base
What do you mean :) ? [EMAIL PROTECTED] wrote: Funniest post ever ! :) I bet they shouldn't have sold knives in the store for some centuries for a similar reason. What do we do with other similar services on the web? P.S. Please don't take it personally. ___ 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: Your One-Stop Site For Sony Lawsuit Info
At the risk of this discussion running far afield, I think Jason and Paul may be talking past each other. My understanding is that Jason has a point -- corporations can't suffer the same punishment as individuals. They aren't deprived of their freedom in prisons. The most common corporate punishment is a fine. Paul's point is SOX, GLBA, and HIPAA hold individuals accountable for their acts at corporations. Those two opinions are both correct, and do not contradict each other. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] [ GLSA 200511-18 ] phpSysInfo: Multiple vulnerabilities
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Gentoo Linux Security Advisory GLSA 200511-18 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - http://security.gentoo.org/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Severity: Normal Title: phpSysInfo: Multiple vulnerabilities Date: November 22, 2005 Bugs: #112482 ID: 200511-18 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Synopsis phpSysInfo is vulnerable to multiple issues, including a local file inclusion leading to information disclosure and the potential execution of arbitrary code. Background == phpSysInfo displays various system stats via PHP scripts. Affected packages = --- Package / Vulnerable / Unaffected --- 1 www-apps/phpsysinfo2.4.1= 2.4.1 Description === Christopher Kunz from the Hardened-PHP Project discovered that phpSysInfo is vulnerable to local file inclusion, cross-site scripting and a HTTP Response Splitting attacks. Impact == A local attacker may exploit the file inclusion vulnerability by sending malicious requests, causing the execution of arbitrary code with the rights of the user running the web server. A remote attacker could exploit the vulnerability to disclose local file content. Furthermore, the cross-site scripting issues gives a remote attacker the ability to inject and execute malicious script code in the user's browser context or to steal cookie-based authentication credentials. The HTTP response splitting issue give an attacker the ability to perform site hijacking and cache poisoning. Workaround == There is no known workaround at this time. Resolution == All phpSysInfo users should upgrade to the latest version: # emerge --sync # emerge --ask --oneshot --verbose =www-apps/phpsysinfo-2.4.1 References == [ 1 ] Original advisory http://www.hardened-php.net/advisory_222005.81.html [ 2 ] CVE-2005-3347 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3347 [ 3 ] CVE-2005-3348 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3348 Availability This GLSA and any updates to it are available for viewing at the Gentoo Security Website: http://security.gentoo.org/glsa/glsa-200511-18.xml Concerns? = Security is a primary focus of Gentoo Linux and ensuring the confidentiality and security of our users machines is of utmost importance to us. Any security concerns should be addressed to [EMAIL PROTECTED] or alternatively, you may file a bug at http://bugs.gentoo.org. License === Copyright 2005 Gentoo Foundation, Inc; referenced text belongs to its owner(s). The contents of this document are licensed under the Creative Commons - Attribution / Share Alike license. http://creativecommons.org/licenses/by-sa/2.0 pgp8gOrp1kelo.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] Re: Your One-Stop Site For Sony Lawsuit Info
Anonymous Squirrel wrote: At the risk of this discussion running far afield, I think Jason and Paul may be talking past each other. My understanding is that Jason has a point -- corporations can't suffer the same punishment as individuals. They aren't deprived of their freedom in prisons. The most common corporate punishment is a fine. Paul's point is SOX, GLBA, and HIPAA hold individuals accountable for their acts at corporations. Those two opinions are both correct, and do not contradict each other. This is true, and important. Nonetheless, Jason seems to be almost calling for mob justice, when he says: The only option available to the people is mob justice. Corporations can be ruined and they can be burned to the ground, but they can't be touched in a meaningful way through mechanisms of law. Corporate persons are truly first-class citizens, rising above the rest of us natural persons in importance and worth to society. Paul Schmehl is pointing out that this is false--the law can be used against corporations, to regulate the acts of corporations by making the persons who constitute their leadership personally liable in criminal court. I strongly doubt that vigilantism is an appropriate or even useful response to corporations victimizing their customers with spyware. I think that we need to start prosecuting people, and work with the law as much as we can. Vigilantism is, in this case, precisely the problem. Sony execs are pissed off at their customers violating their copyright, so they're taking the law into their own hands. This is unacceptable. Ideally, they, and anyone who fools users into installing rootkits on their systems, should be put in jail. Even if we cannot put them in jail now, because the law is to ambiguous to convict beyond reasonable doubt, the solution is to alter the law so that it can be used in this way, by passing laws to make spyware authors and execs ordering the creation and distribution of spyware more criminally liable. Sony and other companies that profit from hurting their customers want us to believe that the only way to stop them is to break the law. That defines them as legitimate and their opponents as illegitimate. When did consumer privacy advocates and activists become rebels? Society has established norms about how people are to treat one another. Executives and computer programmers at Sony have violated those norms. They are the rebel scum, and we must use the law to stop, deter, and punish them. This, along with efforts to educate the public about social, legal, and technical measures for self-defense, will be by far the most pragmatically effective way to protect the privacy and security of the rest of us natural persons. -Eliah ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] [ GLSA 200511-19 ] eix: Insecure temporary file creation
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Gentoo Linux Security Advisory GLSA 200511-19 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - http://security.gentoo.org/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Severity: Normal Title: eix: Insecure temporary file creation Date: November 22, 2005 Bugs: #112061 ID: 200511-19 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Synopsis eix has an insecure temporary file creation vulnerability, potentially allowing a local user to overwrite arbitrary files. Background == eix is a small utility for searching ebuilds with indexing for fast results. Affected packages = --- Package / Vulnerable /Unaffected --- 1 app-portage/eix 0.5.0_pre2= 0.5.0_pre2 *= 0.3.0-r2 Description === Eric Romang discovered that eix creates a temporary file with a predictable name. eix creates a temporary file in /tmp/eix.*.sync where * is the process ID of the shell running eix. Impact == A local attacker can watch the process list and determine the process ID of the shell running eix while the emerge --sync command is running, then create a link from the corresponding temporary file to a system file, which would result in the file being overwritten with the rights of the user running the application. Workaround == There is no known workaround at this time. Resolution == All eix users should upgrade to the latest version: # emerge --sync # emerge --ask --oneshot --verbose app-portage/eix Availability This GLSA and any updates to it are available for viewing at the Gentoo Security Website: http://security.gentoo.org/glsa/glsa-200511-19.xml Concerns? = Security is a primary focus of Gentoo Linux and ensuring the confidentiality and security of our users machines is of utmost importance to us. Any security concerns should be addressed to [EMAIL PROTECTED] or alternatively, you may file a bug at http://bugs.gentoo.org. License === Copyright 2005 Gentoo Foundation, Inc; referenced text belongs to its owner(s). The contents of this document are licensed under the Creative Commons - Attribution / Share Alike license. http://creativecommons.org/licenses/by-sa/2.0 pgpsK4EbRxmlz.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] [ GLSA 200511-20 ] Horde Application Framework: XSS vulnerability
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Gentoo Linux Security Advisory GLSA 200511-20 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - http://security.gentoo.org/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Severity: Low Title: Horde Application Framework: XSS vulnerability Date: November 22, 2005 Bugs: #112491 ID: 200511-20 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Synopsis The Horde Application Framework is vulnerable to a cross-site scripting vulnerability which could lead to the compromise of the victim's browser content. Background == The Horde Application Framework is a general-purpose web application framework written in PHP, providing classes for handling preferences, compression, browser detection, connection tracking, MIME, and more. Affected packages = --- Package / Vulnerable / Unaffected --- 1 www-apps/horde2.2.9 = 2.2.9 Description === The Horde Team reported a potential XSS vulnerability. Horde fails to properly escape error messages which may lead to displaying unsanitized error messages via Notification_Listener::getMessage() Impact == By enticing a user to read a specially-crafted e-mail or using a manipulated URL, an attacker can execute arbitrary scripts running in the context of the victim's browser. This could lead to a compromise of the user's browser content. Workaround == There is no known workaround at this time. Resolution == All Horde Application Framework users should upgrade to the latest version: # emerge --sync # emerge --ask --oneshot --verbose =www-apps/horde-2.2.9 References == [ 1 ] CVE-2005-3570 http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3570 [ 2 ] Horde Announcement http://lists.horde.org/archives/announce/2005/000231.html Availability This GLSA and any updates to it are available for viewing at the Gentoo Security Website: http://security.gentoo.org/glsa/glsa-200511-20.xml Concerns? = Security is a primary focus of Gentoo Linux and ensuring the confidentiality and security of our users machines is of utmost importance to us. Any security concerns should be addressed to [EMAIL PROTECTED] or alternatively, you may file a bug at http://bugs.gentoo.org. License === Copyright 2005 Gentoo Foundation, Inc; referenced text belongs to its owner(s). The contents of this document are licensed under the Creative Commons - Attribution / Share Alike license. http://creativecommons.org/licenses/by-sa/2.0 pgpXc30hGXIoO.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] Re: Your One-Stop Site For Sony Lawsuit Info
Eliah Kagan wrote: Anonymous Squirrel wrote: At the risk of this discussion running far afield, I think Jason and Paul may be talking past each other. My understanding is that Jason has a point -- corporations can't suffer the same punishment as individuals. They aren't deprived of their freedom in prisons. The most common corporate punishment is a fine. Paul's point is SOX, GLBA, and HIPAA hold individuals accountable for their acts at corporations. Those two opinions are both correct, and do not contradict each other. This is true, and important. Nonetheless, Jason seems to be almost calling for mob justice, when he says: The only option available to the people is mob justice. Corporations can be ruined and they can be burned to the ground, but they can't be touched in a meaningful way through mechanisms of law. Corporate persons are truly first-class citizens, rising above the rest of us natural persons in importance and worth to society. Paul Schmehl is pointing out that this is false--the law can be used against corporations, to regulate the acts of corporations by making the persons who constitute their leadership personally liable in criminal court. I strongly doubt that vigilantism is an appropriate or even useful response to corporations victimizing their customers with spyware. I And yet, Jason has a deep point - corporations have more rights than citizens. There is no jail time (freezing of assets and suspension of sales, perhaps?) or death penalty (forced liquidation of assets, distribution of proceeds to bond/stock owners - outside of bankruptcy court) for them, and it's unlikely there ever will be, because they have the money. The penalties should exist and be enforced, IMHO. But this is political discussion, and perhaps not completely relevant to this forum. Kurt ___ 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] XCP2 v XCP - more than sony at fault?
hi, I this this has to be one of the most coherent emails on this subject, and i agree 100% with this post an previous posts in this thread. (i have had a few beers so in reality it might be more like 98%) anyway i digress, My point is/was, This whole backlash has come about because a home music listener, who is computer smart (sorry i dont know enough about you to give you more props) installed a cd that was *bought from a shop* in 2005 and had this issue (XCP2) I think that this rookit shit has been going on since 2002. What i read from that website(first 4) was that sony have been using XCP1 since 2002 on prerelease stuff. Whilst 99% of the population will never own these versions, they will hear them on the radio, before they get to the shops. I want to know if the pre release stuff has teh same issue. (because press and radio stations have been getting these for 3 years!) whilst your (that is not you spesifcally bkfsec) are rught i think you missed my point. The trust thing is paramount in this. I should not have to educate these people not to play CD's from Sont, EMI, etc. they should be safe. end of. no arguments not everyone can be security savvy, it all most of my friends can do to be web savvy... beer is getting hte better of me now, so i best go cheers then S. On 11/22/05, bkfsec [EMAIL PROTECTED] wrote: Larry Seltzer wrote: Running a restricted user account by default would also help (no admin privileges given to the application located on the CD). I recommend everyone to get into this habit when using Windows desktops. In cases in which you need admin privileges to install an application you can just use the command run as by right-clicking on the executable to install. Ditto to all of this. It's not just good practice, it specifically stops the XCP software which reports that it (actually, it says that the music player) requires administrator privileges to install. I'm sure most people would just login as admin and install, but at least at that point you're explicitly pointing the gun at your own head and pulling the trigger. I agree with the general points about using non-privileged users and as well for disabling auto-run. However, I think that you made the right point by saying that most people would just login as admin and install, but I think that this thinking may represent a problem for the information technology industry and security. The problem, of course, is normal users. Yes, security professionals have gotten hit with this. But most security professionals are pretty savvy when it comes to operating their PCs. For the most part, I'm not too concerned with what we do. And we're the only ones who will actually, unfortunately, be helped by these suggestions. Most normal users will still double-click on the CD to execute the content. Most normal users will still happily run as admin in order to execute the installer. Trust is the issue in this situation. People trusted Sony, and Sony violated that trust. Unfortunately, there are no easy solutions. As long as people are allowed to execute random code on their own computers, trust will continue to trip people up. I'm not sure that there is an easy answer to this. But those of us who are security savvy should begin thinking about what our answers will do for the average user. The advice given here is a step in the right direction, but I don't personally believe that it will end the flood of malware and the like out there. I think that the people cracking systems and installing crap like XCP are going to continue doing it, knowing full well that trust is their ally. So what is the solution? I don't know really... it's a tough nut to crack. Education works well, but what do we say in this case? Say Trust no one because large corporations will screw you as badly as everyone else? Thanks Sony - you really made our jobs easier here. /sarcasm And what about the vaunted end goal of hardware-based DRM? Restriction of what can be installed on a person's system. I'm not comfortable with that either... first of all because we all know that it won't take people long to find a way around it and those people illegally distributing malware could care less about violating the DMCA. Second of all because something like that won't stop companies from installing crap like XCP. And third of all because it reduces the ability for people to control their own environments, making crap like XCP harder for people to remove (which is a wholesale loss for the consumer). So what's the permanent fix here? I don't know... I think I, as well as everyone else, am open to new ideas. I think that we, as an industry, need to very seriously think about what the safest method of installing and auditing new code is. The best thing I can think of at the moment is an OS-defined new-code sandbox that can't access anything else until approved... but
Re: [Full-disclosure] Hacking Boot camps!
nicely said. Set up your own lab at home, using vmware or alike and hack, crack all you like. On 11/22/05, InfoSecBOFH [EMAIL PROTECTED] wrote: In my opinion all of the so called hacking training out there is horrible and nothing more than a money grab. Look at the SANS courseware, it is out of date and shit. The best training is to read, google, and play on your own. ___ 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] Re: Google Base
Funniest post ever ! :) I bet they shouldn't have sold knives in the store for some centuries for a similar reason. What do we do with other similar services on the web? P.S. Please don't take it personally. Petko Petkov [EMAIL PROTECTED] 18.11.2005 12:28 To full-disclosure@lists.grok.org.uk, bugtraq@securityfocus.com cc Subject Google Base OK, I need to start this subject since nobody else has discussed anything yet on the mailing list. Do you guys know about Google Base?: Google our big hacker friend that helps us to find malicious scripts and open proxies just like that. Well, Google has a new service: Google Base. And there are many cool stuff that you can do with it. First of all I would like to mention that Google Base is sort of database where you can put whatever information you want: you can blog, you can post your advisories there, you can write awesome worms that upload and read commands from there, you can even use it as the biggest rainbow table in the world that can crack any hash in less than a second. check it out: http://base.google.com I was playing around with goggle base and I must say I am quite impressed and in the same time scared to death. Goggle base is the most amazing thing I have seen for a while and it can be used for many different things. Now here is a list that I built for you how to use goggle base for your own good: * Brute forcer - massive storage for mare mortals. * Keep your exploits * Keep your code fragments * Keep your advisories and security notes * Log there :) * Write a book (Goggle Book) :) * You can write even a Game Book. * Write a game and store its data on goggle base * Use it to hold your secret hacker tools (with encryption) :) just joking * Make a goggle base forum * Make a security list If you have more ideas how to use and abuse goggle base service, just contribute to the thread. Of course we all have to be responsible. This is the reason why I believe that this early notice about goggle base power is fair enough. Cheers ___ 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] Hacking Boot camps!
I went to a 5-day-boot-camp given by a group called The Training Camp - small class size (7), great hands on, everything worked, 12 hour days, they covered tools, techniques, evasion, and detection. There was some knowledge they expected students to already know, such as basic networking concepts, security practices, and vulnerabilities. As far as I know, everyone including myself took and passed the CEH exam on the last day of the class. Are any of us 1337 [EMAIL PROTECTED] now? No. But that was not the point of the class. If that's what you're looking for, try ImmunitySec. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of c0ntex Sent: Tuesday, November 22, 2005 2:46 PM To: K Tucker Cc: full-disclosure@lists.grok.org.uk Subject: Re: [Full-disclosure] Hacking Boot camps! Hmm, there was hands on hacking, but by the company that sold you the training, it sounds like you got owned by salesman.c. Blackhat training camps sound pretty good and some of the people are pretty damn skilled, but these others Zone-H, Vigilante and the likes I would avoid. blind leading the blind if you ask me. I'd research who your mentors were before even thinking about signing, On 22/11/05, K Tucker [EMAIL PROTECTED] wrote: Seems that I read from time to time people asking about the merits of these hacker boot camps. It might be helpful if I relate my recent experience. I attended a 5 day Hacker boot camp conducted by Intense school which is part of Vigilar. Cost was $3200, which I paid out of my own pocket. The salesman I spoke with did a great job selling me on the idea of how hands on it was going to be and all the tools the instructor was going to show us how to use. The classes were supposed to be from 8:30am to 6:00pm for the 5 days. The instructor didn't show up until 4:00 pm due to scheduling conflict. We only received 3 hours that day. The following days started at 9:00 not 8:30 as advertised which might seem like a small thing but at $3200 every minute counts! The real disappointment was the quality of the class. There was little actual lab work. 90% of the class was sitting while the instructor read from the class manual while we looked at a slide of the same page he was reading. Sure it was nice to be read things like CAIN and ABEL is a good program for sniffing networks, but we in the class wanted to know how do you use it! We were never shown. We did have a little hands on lab work which involved ethereal and sam spade and netcat. It was hard to get them to work because none of our vmware was connected to the network correctly so we wasted another hour just trying to get that to work! The feeling in the class was that the class computers should have been set up and ready to go before we even arrived. Friday was the big disappointment. The class began at 9:00am and they started the CEH examine at 11:00 am. That test only lasts 3 hours so by 2:00pm the school was over! Most of the class did not take the test because we didn't feel ready. 5 people in the class did take it and 2 passed it. Those 2 were very experienced in network security. The other 3 failed it. I have emailed Intense school 4 times with my concerns but have never heard back from them. I guess they are not too concerned. My feeling is someone would do much better to just get the book Hacking Exposed and download the suggested tools and play with them. You will learn much more and save a lot of money! __ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.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/ -- regards c0ntex ___ 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] Re: Torrential 1.2 getdox.php Directory Traversal
There is also a XSS vulnerablility present. PoC: http://www.example.com/torrential/dox/getdox.php/scriptalert(hi)/script 2005/11/21, Shell [EMAIL PROTECTED]: I was poking around my own server because I had an installation of torrential and found this vuln. The problem lies in getdox.php. It works by taking an argument after a /. This specifies a file. The DOX folder that it grabs the files from is located int /dox such that / is the directory that the main index is in. Now, you can give it the parameter of /(any file) and it will fetch that file. EXAMPLES: http://www.example.com/torrential/dox/getdox.php/../forums.php (goes to the forums page) http://www.example.com/torrential/dox/getdox.php/../../index.html (goes to http://www.example.com/index.html in this case) LOCATION FOR DOWNLOAD: prdownloads.sourceforge.net/torrentbits/TBSource_-_Torrential_Beta_1.2-2005-09-25-1220-expert01.rar?download I have already taken preventative measures on my site. ___ 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] Hacking Boot camps!
Thats the thing. These are not hacking courses but script kiddie or if you prefer pen-test courses. All these can teach you is to take the known and run it against a box. How is that hacking? ___ 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] Hacking Boot camps!
On Tue, 22 Nov 2005 20:36:01 PST, InfoSecBOFH said: Thats the thing. These are not hacking courses but script kiddie or if you prefer pen-test courses. All these can teach you is to take the known and run it against a box. How is that hacking? Keep in mind that 98% of systems are nailed by either automated worms or people running canned stuff. Just because it's not real hacking doesn't mean it doesn't actually work in practice. pgpTXqKxSriLl.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] [SECURITY] [DSA 907-1] New ipmenu packages fix insecure temporary file creation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Debian Security Advisory DSA 907-1 [EMAIL PROTECTED] http://www.debian.org/security/ Martin Schulze November 23rd, 2005 http://www.debian.org/security/faq - -- Package: ipmenu Vulnerability : insecure temporary file Problem type : local Debian-specific: no CVE ID : CVE-2004-2569 BugTraq ID : 10269 Debian Bug : 244709 Akira Yoshiyama noticed that ipmenu, an cursel iptables/iproute2 GUI, creates a temporary file in an insecure fashion allowing a local attacker to overwrite arbitrary files utilising a symlink attack. For the old stable distribution (woody) this problem has been fixed in version 0.0.3-4woody1 The stable distribution (sarge) does not contain the ipmenu package. For the unstable distribution (sid) this problem has been fixed in version 0.0.3-5. We recommend that you upgrade your ipmenu package. Upgrade Instructions - wget url will fetch the file for you dpkg -i file.deb will install the referenced file. If you are using the apt-get package manager, use the line for sources.list as given below: apt-get update will update the internal database apt-get upgrade will install corrected packages You may use an automated update by adding the resources from the footer to the proper configuration. Debian GNU/Linux 3.0 alias woody - Source archives: http://security.debian.org/pool/updates/main/i/ipmenu/ipmenu_0.0.3-4woody1.dsc Size/MD5 checksum: 561 89c838a80091dd0f86b8fa3455edf519 http://security.debian.org/pool/updates/main/i/ipmenu/ipmenu_0.0.3-4woody1.diff.gz Size/MD5 checksum: 2307 0ba4d3b6153ea509c9d4617f98ae3893 http://security.debian.org/pool/updates/main/i/ipmenu/ipmenu_0.0.3.orig.tar.gz Size/MD5 checksum:27078 e8c5de8c6d8ec97760c1a9d39d90fb18 Architecture independent components: http://security.debian.org/pool/updates/main/i/ipmenu/ipmenu_0.0.3-4woody1_all.deb Size/MD5 checksum:23150 85df22e0cb86e28f3a57ed2687d7b863 These files will probably be moved into the stable distribution on its next update. - - For apt-get: deb http://security.debian.org/ stable/updates main For dpkg-ftp: ftp://security.debian.org/debian-security dists/stable/updates/main Mailing list: debian-security-announce@lists.debian.org Package info: `apt-cache show pkg' and http://packages.debian.org/pkg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDg/pkW5ql+IAeqTIRAnYEAKCewjawc7AzOXYk5i9QSa8lN5SNCgCfYNyS xTYJBziB+6A/w6dj5sP0/RA= =IaUB -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] Host fingerprinting with hping [paper]
This paper discusses some of the techniques that can be effectively used in host fingerprinting. The paper will specially cover the cases where network hosts are behind firewalls. We will explain the techniques with various tools but the majority of the work is based on a simple and powerful utility named hping. The OS fingerprinting is reviwed in certain fire walled environments, also it has been tried to analyze the methods in detail that brings us the advantages and disadvantages of some techniques and the usage of hping as an auditing tool. The original paper can be found here http://bsdpakistan.org/downloads/HostFingerprinting.pdf naveed NUCES-FAST LHR ___ 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] Hacking Boot camps!
Speaking of script kiddie stuff... bbs's and the like... anyone remember VCL?.. virus creation labratory? -Jeff Wilder CISSP,CCE,C/EH -BEGIN GEEK CODE BLOCK- Version: 3.1 GIT/CM/CS/O d- s:+ a C+++ UH++ P L++ E- w-- N+++ o-- K- w O- M-- V-- PS+ PE- Y++ PGP++ t+ 5- X-- R* tv b++ DI++ D++ G e* h--- r- y+++* --END GEEK CODE BLOCK-- From: ReK2GNULinux [EMAIL PROTECTED] To: Ivan . [EMAIL PROTECTED] CC: full-disclosure@lists.grok.org.uk Subject: Re: [Full-disclosure] Hacking Boot camps! Date: Tue, 22 Nov 2005 20:14:05 -0500 MIME-Version: 1.0 Received: from lists.grok.org.uk ([195.184.125.51]) by mc10-f28.hotmail.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 22 Nov 2005 17:14:58 -0800 Received: from lists.grok.org.uk (localhost [127.0.0.1])by lists.grok.org.uk (Postfix) with ESMTP id 11F78FC2;Wed, 23 Nov 2005 01:14:26 + (GMT) Received: from stargate.binaryfreedom.info(207-172-223-37.c3-0.wob-ubr3.sbo-wob.ma.cable.rcn.com[207.172.223.37])by lists.grok.org.uk (Postfix) with ESMTP id B2903EA3for full-disclosure@lists.grok.org.uk;Wed, 23 Nov 2005 01:14:16 + (GMT) Received: from localhost (localhost [127.0.0.1])by stargate.binaryfreedom.info (Postfix) with ESMTP id 2C0475419D;Tue, 22 Nov 2005 19:52:00 -0500 (EST) Received: from stargate.binaryfreedom.info ([127.0.0.1])by localhost (stargate.binaryfreedom.info [127.0.0.1]) (amavisd-new,port 10024)with ESMTP id 25639-01; Tue, 22 Nov 2005 19:51:50 -0500 (EST) Received: from [127.0.0.1] (209-6-98-146.c3-0.wob-ubr3.sbo-wob.ma.cable.rcn.com[209.6.98.146])by stargate.binaryfreedom.info (Postfix) with ESMTP id BF00C54034;Tue, 22 Nov 2005 19:51:50 -0500 (EST) X-Message-Info: JGTYoYF78jGmv6T0JK0gGy+lZZ4AeY+/bvh5CXzmlN8= X-Original-To: full-disclosure@lists.grok.org.uk Delivered-To: full-disclosure@lists.grok.org.uk User-Agent: Thunderbird 1.5 (Windows/20051025) References: [EMAIL PROTECTED] [EMAIL PROTECTED][EMAIL PROTECTED] X-Virus-Scanned: by amavisd-new at stargate.binaryfreedom.info X-BeenThere: full-disclosure@lists.grok.org.uk X-Mailman-Version: 2.1.5 Precedence: list List-Id: An unmoderated mailing list for the discussion of security issuesfull-disclosure.lists.grok.org.uk List-Unsubscribe: https://lists.grok.org.uk/mailman/listinfo/full-disclosure, mailto:[EMAIL PROTECTED] List-Archive: http://lists.grok.org.uk/pipermail/full-disclosure List-Post: mailto:full-disclosure@lists.grok.org.uk List-Help: mailto:[EMAIL PROTECTED] List-Subscribe: https://lists.grok.org.uk/mailman/listinfo/full-disclosure, mailto:[EMAIL PROTECTED] Errors-To: [EMAIL PROTECTED] Return-Path: [EMAIL PROTECTED] X-OriginalArrivalTime: 23 Nov 2005 01:15:02.0075 (UTC) FILETIME=[543F20B0:01C5EFCB] I agree that is how we did it 10 + years a go there were no courses, no books, just BBS's with docs and ezines. and still the best way of doing it. Chris Fernandez Ivan . wrote: nicely said. Set up your own lab at home, using vmware or alike and hack, crack all you like. On 11/22/05, InfoSecBOFH [EMAIL PROTECTED] wrote: In my opinion all of the so called hacking training out there is horrible and nothing more than a money grab. Look at the SANS courseware, it is out of date and shit. The best training is to read, google, and play on your own. ___ 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/ -- --- | I WON'T TRADE HUMANISM FOR PATRIOTISM | --- dias que se acuesta uno sin aprender algo es un dia malgastado Microsoft is not the answer, Microsoft is the question, the answer is no. gtalk: [EMAIL PROTECTED] jabber: [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 - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] [SECURITY] [DSA 908-1] New sylpheed-claws packages fix arbitrary code execution
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Debian Security Advisory DSA 908-1 [EMAIL PROTECTED] http://www.debian.org/security/ Martin Schulze November 23rd, 2005 http://www.debian.org/security/faq - -- Package: sylpheed-claws Vulnerability : buffer overflows Problem type : remote Debian-specific: no CVE ID : CVE-2005-3354 CERT advisory : BugTraq ID : Debian Bug : 338436 Colin Leroy discovered several buffer overflows in a number of importer routines in sylpheed-claws, an extended version of the Sylpheed mail client, that could lead to the execution of arbitrary code. The following matrix explains which versions fix this vulnerability old stable (woody) stable (sarge) unstable (sid) sylpheed 0.7.4-4woody1 1.0.4-1sarge1 2.0.4-1 sylpheed-gtk1 n/a n/a 1.0.6-1 sylpheed-claws 0.7.4claws-3woody1 1.0.4-1sarge1 1.0.5-2 sylpheed-claws-gtk2n/a n/a 1.9.100-1 We recommend that you upgrade your sylpheed-claws package. Upgrade Instructions - wget url will fetch the file for you dpkg -i file.deb will install the referenced file. If you are using the apt-get package manager, use the line for sources.list as given below: apt-get update will update the internal database apt-get upgrade will install corrected packages You may use an automated update by adding the resources from the footer to the proper configuration. Debian GNU/Linux 3.0 alias woody - Source archives: http://security.debian.org/pool/updates/main/s/sylpheed-claws/sylpheed-claws_0.7.4claws-3woody1.dsc Size/MD5 checksum: 848 bd9c000540b1a1b55744beb62f212c64 http://security.debian.org/pool/updates/main/s/sylpheed-claws/sylpheed-claws_0.7.4claws-3woody1.diff.gz Size/MD5 checksum:20480 1237f7502e05fe2fb32c4ae481c16cf7 http://security.debian.org/pool/updates/main/s/sylpheed-claws/sylpheed-claws_0.7.4claws.orig.tar.gz Size/MD5 checksum: 1838954 e3558cefc1c8c4440b7e6b1b72cdad04 Alpha architecture: http://security.debian.org/pool/updates/main/s/sylpheed-claws/sylpheed-claws_0.7.4claws-3woody1_alpha.deb Size/MD5 checksum: 1309678 b3c74ce2833655dba1e173c438877467 ARM architecture: http://security.debian.org/pool/updates/main/s/sylpheed-claws/sylpheed-claws_0.7.4claws-3woody1_arm.deb Size/MD5 checksum: 1188878 c437f612c996ee8d83e55f85cff7cf37 Intel IA-32 architecture: http://security.debian.org/pool/updates/main/s/sylpheed-claws/sylpheed-claws_0.7.4claws-3woody1_i386.deb Size/MD5 checksum: 1165964 1dc10653fc2768835196e88d3e823e6e Intel IA-64 architecture: http://security.debian.org/pool/updates/main/s/sylpheed-claws/sylpheed-claws_0.7.4claws-3woody1_ia64.deb Size/MD5 checksum: 1501644 85ba341c8d598271f52a2fb772418c9e HP Precision architecture: http://security.debian.org/pool/updates/main/s/sylpheed-claws/sylpheed-claws_0.7.4claws-3woody1_hppa.deb Size/MD5 checksum: 1300120 2ecb96eb587cbc00af32e47c218ddd36 Motorola 680x0 architecture: http://security.debian.org/pool/updates/main/s/sylpheed-claws/sylpheed-claws_0.7.4claws-3woody1_m68k.deb Size/MD5 checksum: 1127424 92bf03269263f338aead1a212f54c550 Big endian MIPS architecture: http://security.debian.org/pool/updates/main/s/sylpheed-claws/sylpheed-claws_0.7.4claws-3woody1_mips.deb Size/MD5 checksum: 1202180 11e7addcaadd3047814dd0cb7ef9ad00 Little endian MIPS architecture: http://security.debian.org/pool/updates/main/s/sylpheed-claws/sylpheed-claws_0.7.4claws-3woody1_mipsel.deb Size/MD5 checksum: 1193116 182d89e8db3d7d78f1b24f596389b5f9 PowerPC architecture: http://security.debian.org/pool/updates/main/s/sylpheed-claws/sylpheed-claws_0.7.4claws-3woody1_powerpc.deb Size/MD5 checksum: 1196852 ea5b7563191c0f03da75a7a435a8645d IBM S/390 architecture: http://security.debian.org/pool/updates/main/s/sylpheed-claws/sylpheed-claws_0.7.4claws-3woody1_s390.deb Size/MD5 checksum: 1168114 0117a0496b263a8445874b8c08ddf8b7 Sun Sparc architecture: http://security.debian.org/pool/updates/main/s/sylpheed-claws/sylpheed-claws_0.7.4claws-3woody1_sparc.deb Size/MD5 checksum: 1186542 1c0db9796cb52c2558f3ce9b72571890 Debian GNU/Linux 3.1 alias sarge - Source archives: http://security.debian.org/pool/updates/main/s/sylpheed-claws/sylpheed-claws_1.0.4-1sarge1.dsc Size/MD5 checksum: 1282 a374fa1bbc73375f217a8babc579809b
