[Full-disclosure] QUANTUMSQUIRREL - attrition.org unmasked as NSA TAO OP
Jericho has some 'splaining to do! c.f. QUANTUMSQUIRREL** clearly the squirrel schwag is just cover for the _real_ rogue revenues... ** https://peertech.org/files/QUANTUMSQUIRREL.JPG attachment: QUANTUMSQUIRREL.JPG___ 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] [ MDVSA-2014:051 ] file
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ___ Mandriva Linux Security Advisory MDVSA-2014:051 http://www.mandriva.com/en/support/security/ ___ Package : file Date: March 13, 2014 Affected: Business Server 1.0 ___ Problem Description: Updated file package fixes security vulnerability: It was discovered that file before 5.17 contains a flaw in the handling of indirect magic rules in the libmagic library, which leads to an infinite recursion when trying to determine the file type of certain files (CVE-2014-1943). Additionally, other well-crafted files might result in long computation times (while using 100% CPU) and overlong results. A flaw was found in the way the file utility determined the type of Portable Executable (PE) format files, the executable format used on Windows. A malicious PE file could cause the file utility to crash or, potentially, execute arbitrary code (CVE-2014-2270). A memory leak in file has also been fixed. The affected packages have been upgraded to the 5.12 version and patched to correct these flaws. ___ References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-1943 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-2270 http://advisories.mageia.org/MGASA-2014-0092.html http://advisories.mageia.org/MGASA-2014-0123.html ___ Updated Packages: Mandriva Business Server 1/X86_64: 5daf7e68d436107f087e08cbabd55a53 mbs1/x86_64/file-5.12-1.mbs1.x86_64.rpm f59233880c730cd02d6e9c9bc2b50040 mbs1/x86_64/lib64magic1-5.12-1.mbs1.x86_64.rpm 9d5063b1d1e64d82df88ec926e26be58 mbs1/x86_64/lib64magic-devel-5.12-1.mbs1.x86_64.rpm 672916960ebde988649acb12fa9ff534 mbs1/x86_64/lib64magic-static-devel-5.12-1.mbs1.x86_64.rpm f2a64add383b5d18ae6f0c29c2972a49 mbs1/x86_64/python-magic-5.12-1.mbs1.noarch.rpm a60928e3e2bc266079b8466bd9519eb0 mbs1/SRPMS/file-5.12-1.mbs1.src.rpm ___ To upgrade automatically use MandrivaUpdate or urpmi. The verification of md5 checksums and GPG signatures is performed automatically for you. All packages are signed by Mandriva for security. You can obtain the GPG public key of the Mandriva Security Team by executing: gpg --recv-keys --keyserver pgp.mit.edu 0x22458A98 You can view other update advisories for Mandriva Linux at: http://www.mandriva.com/en/support/security/advisories/ If you want to report vulnerabilities, please contact security_(at)_mandriva.com ___ Type Bits/KeyID Date User ID pub 1024D/22458A98 2000-07-10 Mandriva Security Team security*mandriva.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iD8DBQFTIVxsmqjQ0CJFipgRApnoAJ0WKcVX9puBlpl8mkzhhy8+lFf1DwCeKbTX B0zUUM//h2BC4yyN9jxSSJU= =M1BL -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] [ MDVSA-2014:052 ] net-snmp
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ___ Mandriva Linux Security Advisory MDVSA-2014:052 http://www.mandriva.com/en/support/security/ ___ Package : net-snmp Date: March 13, 2014 Affected: Business Server 1.0 ___ Problem Description: Updated net-snmp packages fix two vulnerabilities: Remotely exploitable denial of service vulnerability in Net-SNMP, in the Linux implementation of the ICMP-MIB, making the SNMP agent vulnerable if it is making use of the ICMP-MIB table objects (CVE-2014-2284). Remotely exploitable denial of service vulnerability in Net-SNMP, in snmptrapd, due to how it handles trap requests with an empty community string when the perl handler is enabled (CVE-2014-2285). ___ References: http://cve.mitre.org/cgi-bin/cvename.cgi?name= http://cve.mitre.org/cgi-bin/cvename.cgi?name= http://advisories.mageia.org/MGASA-2014-0122.html ___ Updated Packages: Mandriva Business Server 1/X86_64: 75e24feeb05a77c70995a9a1175da857 mbs1/x86_64/lib64net-snmp30-5.7.2-1.1.mbs1.x86_64.rpm 2eda4de0bd258d015818e0b18de62453 mbs1/x86_64/lib64net-snmp-devel-5.7.2-1.1.mbs1.x86_64.rpm 280aa9c311cd4373fd0001ad0b1ac3b3 mbs1/x86_64/lib64net-snmp-static-devel-5.7.2-1.1.mbs1.x86_64.rpm e2e77246cbcf195d3842c029e3e17f80 mbs1/x86_64/net-snmp-5.7.2-1.1.mbs1.x86_64.rpm 832ac7ed2bbdc701173d3042d862f8b6 mbs1/x86_64/net-snmp-mibs-5.7.2-1.1.mbs1.x86_64.rpm dbde6cc67a4610c2d2a1aa23e30f2417 mbs1/x86_64/net-snmp-tkmib-5.7.2-1.1.mbs1.x86_64.rpm 5c2a7541316aa4f4eddfe19fe04fd97f mbs1/x86_64/net-snmp-trapd-5.7.2-1.1.mbs1.x86_64.rpm 87162adb1b12d29070b53257ceeef286 mbs1/x86_64/net-snmp-utils-5.7.2-1.1.mbs1.x86_64.rpm 7e2681b068903c4e28dd5d31ca37ef70 mbs1/x86_64/perl-NetSNMP-5.7.2-1.1.mbs1.x86_64.rpm ed8bcbc6470482d1e78567d06e8e608a mbs1/x86_64/python-netsnmp-5.7.2-1.1.mbs1.x86_64.rpm 5c6e6b75f38386964efe4340b2436873 mbs1/SRPMS/net-snmp-5.7.2-1.1.mbs1.src.rpm ___ To upgrade automatically use MandrivaUpdate or urpmi. The verification of md5 checksums and GPG signatures is performed automatically for you. All packages are signed by Mandriva for security. You can obtain the GPG public key of the Mandriva Security Team by executing: gpg --recv-keys --keyserver pgp.mit.edu 0x22458A98 You can view other update advisories for Mandriva Linux at: http://www.mandriva.com/en/support/security/advisories/ If you want to report vulnerabilities, please contact security_(at)_mandriva.com ___ Type Bits/KeyID Date User ID pub 1024D/22458A98 2000-07-10 Mandriva Security Team security*mandriva.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iD8DBQFTIV4rmqjQ0CJFipgRAgWkAJ45l7yEOU6KIy3ySIumvZB0eShVQwCfW1Bh zMDFEhf4YiB6foTD9u+uUPs= =STrP -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] [ MDVSA-2014:053 ] libssh
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ___ Mandriva Linux Security Advisory MDVSA-2014:053 http://www.mandriva.com/en/support/security/ ___ Package : libssh Date: March 13, 2014 Affected: Business Server 1.0 ___ Problem Description: Updated libssh package fixes security vulnerability: When using libssh before 0.6.3, a libssh-based server, when accepting a new connection, forks and the child process handles the request. The RAND_bytes() function of openssl doesn#039;t reset its state after the fork, but simply adds the current process id (getpid) to the PRNG state, which is not guaranteed to be unique. The most important consequence is that servers using EC (ECDSA) or DSA certificates may under certain conditions leak their private key (CVE-2014-0017). ___ References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0017 http://advisories.mageia.org/MGASA-2014-0119.html ___ Updated Packages: Mandriva Business Server 1/X86_64: eb6bcbc277a01a3bcc53d43b127becbe mbs1/x86_64/lib64ssh4-0.5.2-2.2.mbs1.x86_64.rpm 417ce1525889e70932b44399293791b0 mbs1/x86_64/lib64ssh-devel-0.5.2-2.2.mbs1.x86_64.rpm d4bbda02ed47d9b0df5f9e7992a29d6e mbs1/SRPMS/libssh-0.5.2-2.2.mbs1.src.rpm ___ To upgrade automatically use MandrivaUpdate or urpmi. The verification of md5 checksums and GPG signatures is performed automatically for you. All packages are signed by Mandriva for security. You can obtain the GPG public key of the Mandriva Security Team by executing: gpg --recv-keys --keyserver pgp.mit.edu 0x22458A98 You can view other update advisories for Mandriva Linux at: http://www.mandriva.com/en/support/security/advisories/ If you want to report vulnerabilities, please contact security_(at)_mandriva.com ___ Type Bits/KeyID Date User ID pub 1024D/22458A98 2000-07-10 Mandriva Security Team security*mandriva.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iD8DBQFTIV92mqjQ0CJFipgRAn1pAKCI59sSMco0u5/Ff4pa3ut5fvAF/wCgptxb 9kuUknjWGT8mtgJ/+ZmIYwM= =cv+v -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] [ MDVSA-2014:054 ] otrs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ___ Mandriva Linux Security Advisory MDVSA-2014:054 http://www.mandriva.com/en/support/security/ ___ Package : otrs Date: March 13, 2014 Affected: Business Server 1.0 ___ Problem Description: Updated otrs package fixes security vulnerability: An attacker could send a specially prepared HTML email to OTRS. If he can then trick an agent into following a special link to display this email, JavaScript code would be executed (CVE-2014-1695). ___ References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-1695 http://advisories.mageia.org/MGASA-2014-0114.html ___ Updated Packages: Mandriva Business Server 1/X86_64: f913ce8f777c607662375c4cd63995b3 mbs1/x86_64/otrs-3.2.15-1.mbs1.noarch.rpm cf451c6dc24d227df81f277d0542cb9e mbs1/SRPMS/otrs-3.2.15-1.mbs1.src.rpm ___ To upgrade automatically use MandrivaUpdate or urpmi. The verification of md5 checksums and GPG signatures is performed automatically for you. All packages are signed by Mandriva for security. You can obtain the GPG public key of the Mandriva Security Team by executing: gpg --recv-keys --keyserver pgp.mit.edu 0x22458A98 You can view other update advisories for Mandriva Linux at: http://www.mandriva.com/en/support/security/advisories/ If you want to report vulnerabilities, please contact security_(at)_mandriva.com ___ Type Bits/KeyID Date User ID pub 1024D/22458A98 2000-07-10 Mandriva Security Team security*mandriva.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iD8DBQFTIWA2mqjQ0CJFipgRAmAyAJ4soLFUh+CytH8YdDnszYsa26wzjwCghyCb IuQkiqLATAUUnFETQnEXFjk= =t1Xt -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] [ MDVSA-2014:055 ] owncloud
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ___ Mandriva Linux Security Advisory MDVSA-2014:055 http://www.mandriva.com/en/support/security/ ___ Package : owncloud Date: March 13, 2014 Affected: Business Server 1.0 ___ Problem Description: Updated owncloud packages fix security vulnerabilities and bugs: Owncloud versions 5.0.15 and 6.0.2 fix several unspecified security vulnerabilities, as well as many other bugs. See the upstream Changelog for more information. ___ References: http://advisories.mageia.org/MGASA-2014-0120.html http://owncloud.org/changelog/ ___ Updated Packages: Mandriva Business Server 1/X86_64: f17711b6066dab82f39509437f04e75d mbs1/x86_64/owncloud-5.0.15-1.mbs1.noarch.rpm a434bc4843526f2c183746e016444cf4 mbs1/SRPMS/owncloud-5.0.15-1.mbs1.src.rpm ___ To upgrade automatically use MandrivaUpdate or urpmi. The verification of md5 checksums and GPG signatures is performed automatically for you. All packages are signed by Mandriva for security. You can obtain the GPG public key of the Mandriva Security Team by executing: gpg --recv-keys --keyserver pgp.mit.edu 0x22458A98 You can view other update advisories for Mandriva Linux at: http://www.mandriva.com/en/support/security/advisories/ If you want to report vulnerabilities, please contact security_(at)_mandriva.com ___ Type Bits/KeyID Date User ID pub 1024D/22458A98 2000-07-10 Mandriva Security Team security*mandriva.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iD8DBQFTIWFMmqjQ0CJFipgRAviGAJ0cr80Fvn/efM4RuxyBA0Me4LgehgCgrYU0 ZEVpHdzwvkLeBxR3d0tUfSE= =XyRH -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 2877-1] lighttpd security update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 - - Debian Security Advisory DSA-2877-1 secur...@debian.org http://www.debian.org/security/ Michael Gilbert March 12, 2014 http://www.debian.org/security/faq - - Package: lighttpd CVE ID : CVE-2014-2323 CVE-2014-2324 Debian Bug : 741493 Several vulnerabilities were discovered in the lighttpd web server. CVE-2014-2323 Jann Horn discovered that specially crafted host names can be used to inject arbitrary MySQL queries in lighttpd servers using the MySQL virtual hosting module (mod_mysql_vhost). This only affects installations with the lighttpd-mod-mysql-vhost binary package installed and in use. CVE-2014-2324 Jann Horn discovered that specially crafted host names can be used to traverse outside of the document root under certain situations in lighttpd servers using either the mod_mysql_vhost, mod_evhost, or mod_simple_vhost virtual hosting modules. Servers not using these modules are not affected. For the oldstable distribution (squeeze), these problems have been fixed in version 1.4.28-2+squeeze1.6. For the stable distribution (wheezy), these problems have been fixed in version 1.4.31-4+deb7u3. For the testing distribution (jessie), these problems will be fixed soon. For the unstable distribution (sid), these problems have been fixed in version 1.4.33-1+nmu3. We recommend that you upgrade your lighttpd packages. Further information about Debian Security Advisories, how to apply these updates to your system and frequently asked questions can be found at: http://www.debian.org/security/ Mailing list: debian-security-annou...@lists.debian.org -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQQcBAEBCgAGBQJTISlcAAoJELjWss0C1vRzdLsf/1umcpRFMVfpb8kJhN9f+KiN qDASrwyL92FjUknXMP3PjeromIVODaPsCRK9C6zzeCCbNhk97Q2B2fFGVgEVaMmr v52T6PMyQy0bmWHy1O/aC30JBK5CAs0f/IWscqdKvNsOOTx+lVyWRsdRQfK059i1 otvQBsh25ro7jTGXcK1JA1ZTlpr41tmJoTyZR7npY5pEpVq9R9Sjyf/rnKv9RZHW MJaH3mD8J3gSlQyI+Ff8mAaCI2eMfBUocbAgRZRUwD1jGAM8OSr+PhmTTuMZTUq+ vsa68sLUwUiS10/nJVZDqH5TTcEgs9f1MnOpuBGtpdtw1pMAF51j73crEiJwXpUl jIFvPvBopU1I6EQ2NEz8rj+WCbFeY6kE2FdZmJzUCG5qzBb07Uj0mAgIu8jr1XCJ iEo6ngK3PWrG+8gWl2z7yUT8IrTYValb6Al1rr2NeW3QlfBgSSRtKtpYJ+QU4Jb4 +/7wMUTTwN4G3OzeugB1541CH6KaVSR+1R7BaI+sLvPwf4CSQB3SY04nwRdoYJGg La92sLzDI6tc0ETtgApa7akWYvpTcb940SYnUrjz56TOUUdfnDh1ELseFgVAHScz GqiiPcXm17C7O1SVjUq4VO6NAGgwoBBGdwozK1+FoiSka353rnPB4Sf6pGK9Z/ng M41qbfBEvSRyUi+6Y4tipRujgRceZwPzXa/ASEGNv98apXaLcMPFhcq5EY7VEY3u xsAqswdbGUea817rm0XO4A20rwCxCatU61ftDHmsrhwqf2HRzfCgYvFx9JF0S36P JllrmZqt2wwoZDDQZFKimFGd+UAvRzIjW+Gj3Z1a3LGzn/eRj756TsCZh3D/hGdx iBYYZoYY1DYJ1myL0m4MJxugVkMIAEerVcWVzAjDd6lKhFHLHpa6WPQENEYBw9ek ClB7bPLRwXiy2UGk4akMznl/vsMhzj++p/zN07sLnZWMLEvxSggGmiFhE9+IHvCp WFJsvc0+miqyJboy7GX3rjNGAoc7yvwsdPm4wwpGJSqC8N/ZDkUCYe5nHmcHt79f zo/5lUOa87RW/RlrToCig4adXbwk6AKWaoBu7k+C2+VZeIGqHS2oeZrAYhVHDt/A omFUi2wCN8kQPqDuX8e0EXH+AfinBs+vqB9pavFgMYverqrIoXeL3PPC9XqhAvAf 6yIj9HqFNmLCfBtw3JRLFnnzeErPJvR5/FNYh1yeW/OR8b2B5mnyYeU038aB/j3A /zsrRABWKdfvb2tTA5cl6DhxBaPKjUJ29ha6325QOLinhbbInKqRrMMjUDqdS2Cy QD5D2wHpd7ZMbhsa9FDklWnoKcbn5dWp0dUnfkhG8biZsU8bBEdY8gwJS0gD468= =z7Zk -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] Byte CMS Cross Site Scripting Vulnerabilities
# Exploit Title: Byte CMS Cross Site Scripting Vulnerabilities # Date: 02/03/2014 # Exploit Author: projectzero labs # Projectzero ID: projectzero2014-003-bytecmsxss # Vendor Homepage: http://www.bitsnbytes.gr # Software Link: N/A - Commercial # Tested on: Kali Linux / Iceweasel v.22 Mac OS X 10.8.5 / Firefox 27.0.1 About the software: === Byte CMS is a commercial content management system developed by BitsnBytes (www.bitsnbytes.gr) Vulnerability Details: == projectzero labs identified a cross site scripting vulnerability in many variables of the Byte CMS software, which allows an attacker to execute a dynamic script (e.g. JavaScript) in the context of the application. This allows several different attack opportunities, mostly hijacking the current session of the user or changing the look of the page by changing the HTML on the fly to steal the user's credentials. This happens because the user input is interpreted as HTML/JavaScript by the browser. Cross-site scripting targets the users of an application instead of the server. Although this is a limitation, since it allows attackers to hijack other users' sessions, an attacker could target an administrator in order to gain full control over the application. Proof Of Concept: = The cross site scripting vulnerability was found in many variables e.g. id, cid, images etc.The security issue might exist in additional variables but wasn't verified due to the nature of the audit (black-box). We must mention that the CMS applies a typical XSS filtering that can be easily bypassed. For the proof of concept we provide some of the vulnerable sites with the XSS payload trigger: http://www.bitsnbytes.gr/fss/slider.php?images='--/style/scRiptscRiptalert(0xDB)/scRipt http://www.bitsnbytes.gr/all.php?goto='--/style/scRiptscRiptalert(0xBC)/scRipt http://stokokkino.gr/mp3.php?id='--/style/scRiptscRiptalert(0x000104)/scRiptw=300h=23a=0 http://www.thepressproject.gr/list.php?cid='--/style/scRiptscRiptalert(0x000202)/scRipt http://www.msfree.gr/list.php?cid='--/style/scRiptscRiptalert(0x000202)/scRipt http://www.rednotebook.gr/details.php?id='--/style/scRiptscRiptalert(0x000139)/scRipt http://www.rednotebook.gr/report.php?id='--/style/scRiptscRiptalert(0x00016B)/scRiptarticle=704action=edit http://www.autofree.gr/ms.php?id='--/style/scRiptscRiptalert(0x000361)/scRipt Severity: = Medium Disclosure Timeline: Vendor Contact: 23/12/2013 (Contacted vendor in person) 09/01/2014 (1st email - no response about the fix) 15/01/2014 (2nd email - no response about the fix) 02/03/2014 (Email to the site owners) 02/03/2014 Public Disclosure Credits: projectzero labs l...@projectzero.gr http://www.projectzero.gr -- Project Zero Labs http://www.projectzero.gr ___ 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] PowerArchiver: Uses insecure legacy PKZIP encryption when AES is selected (CVE-2014-2319)
PowerArchiver: Uses insecure legacy PKZIP encryption when AES is selected (CVE-2014-2319) References http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-2319 http://int21.de/cve/CVE-2014-2319-powerarchiver.html http://www.powerarchiver.com/2014/03/12/powerarchiver-2013-14-02-05-released/ Background ftp://utopia.hacktic.nl/pub/crypto/cracking/pkzip.ps.gz Description The compression tool PowerArchiver version 14.02.03 creates files with an insecure encryption method even if the user selects a (secure) AES encryption in the GUI. If a user clicks on the Encrypt Files and selects AES 256-bit for encryption, the outcoming file will not be AES-encrypted. It will instead use the legacy PKZIP encryption, which uses a broken encryption algorithm. Note that there are different ways in PowerArchiver to create an encrypted ZIP file, the issue only appears when using the Encrypt Files-Button. The PKZIP encryption has been broken by Biham/Kocher in 1994. The vendor ConeXware has released version 14.02.05 which fixes the issue. It also disables completely support for creating archives with the broken legacy ZIP encryption. Disclosure Timeline 2014-03-10: Issue found, vendor contacted 2014-03-10: Vendor replies, confirms issue 2014-03-12: Vendor publishes fixed version -- Hanno Böck http://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42 signature.asc Description: PGP signature ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] OT What is happening with bitcoins?
Be careful about those zip files. I haven't looked, but they may contain the tibannebackoffice.exe wallet stealing malware. It has appeared in other MtGox2014Leak.zip files. http://www.reddit.com/r/Bitcoin/comments/200k30/the_tibannebackofficeexe_executable_is_wallet/ Mark M. Jaycox | 415.436.9333x128 Electronic Frontier Foundation | Become a Member! eff.org/r.a9hS On 3/10/14 12:54 AM, coderman wrote: On Thu, Mar 6, 2014 at 4:09 PM, Pedro Worcel pe...@worcel.com wrote: Bitcoins are doing great actually. =) Used to be worth 0 a few years back, useless, and now you can use them to buy some stuff. also providing some awesome information for future uses, c.f.: http://blog.magicaltux.net/wp-content/uploads/2014/03/MtGox2014Leak.zip http://89.248.171.30/MtGox2014Leak.zip https://mega.co.nz/#!0VliDQBA!4Ontdi2MsLD4J5dV1-sr7pAgEYTSMi8rNeEMBikEhAs http://burnbit.com/download/280433/MtGox2014Leak_zip let me know if you're still short a mirror... ___ 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] BSides Connecticut - Call for Speakers
Greetings I'm one of the organizers of BSides Connecticut. We're seeking qualified, intelligent, and engaging speakers to speak about, and show off the information security topics or projects that you're passionate about .BSides Connecticut is an awesome day long information security conference hosted at Quinnipiac University's beautiful York Hill campus. The campus sits adjacent to the picturesque peaks of Sleeping Giant Mountain in Hamden, Connecticut, which is just 90 minutes from New York City, two hours from Boston, and just eight miles north of New Haven. With this ideal venue for collaborative presentations, sharing of information and ideas, BSides Connecticut is set to be one of the most memorable and awesome conferences but we need your help. If you're interested in speaking at this very awesome conference please visit our CFP and event page at http://goo.gl/iO4dF8 and submit your talk. *Event Info* - Date: Saturday, June 14th - Time: 10AM to 5PM - Venue: Rocky Top Student Center, Quinnipiac University, 305 Sherman Ave Hamden, CT 06518 - Attendees: Up to 150 individuals interested in information security - Admission: No charge, but space is limited - Website: http://goo.gl/iO4dF8 Questions? Comments? Email me. -- William F. Reyor President NESIT Inc. wre...@nesit.org 290 Pratt St, 2nd Floor, Meriden, CT 06450 ___ 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] Google vulnerabilities with PoC
Google vulnerabilities uncovered... http://news.softpedia.com/news/Expert-Finds-File-Upload-Vulnerability-in-YouTube-Google-Denies-It-s-a-Security-Issue-431489.shtml ___ 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] Medium severity flaw in BlackBerry QNX Neutrino RTOS
Might have been helpful to attach the advisory. Tim -- Tim Brown mailto:t...@nth-dimension.org.uk http://www.nth-dimension.org.uk/ NDSA20140311.txt.asc Description: PGP signature signature.asc Description: This is a digitally signed message part. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] [ MDVSA-2014:056 ] apache-commons-fileupload
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ___ Mandriva Linux Security Advisory MDVSA-2014:056 http://www.mandriva.com/en/support/security/ ___ Package : apache-commons-fileupload Date: March 13, 2014 Affected: Business Server 1.0 ___ Problem Description: Updated apache-commons-fileupload packages fix security vulnerability: It was discovered that the Apache Commons FileUpload package for Java could enter an infinite loop while processing a multipart request with a crafted Content-Type, resulting in a denial-of-service condition (CVE-2014-0050). Tomcat 7 includes an embedded copy of the Apache Commons FileUpload package, and was affected as well. Additionally a build problem with maven was discovered, fixed maven packages is also being provided with this advisory. ___ References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0050 http://advisories.mageia.org/MGASA-2014-0109.html http://advisories.mageia.org/MGASA-2014-0110.html ___ Updated Packages: Mandriva Business Server 1/X86_64: 3ca8ae458a2a14d7fbb0a70c0b713694 mbs1/x86_64/apache-commons-fileupload-1.2.2-7.1.mbs1.noarch.rpm 3b08f11ad938172850ef4ee3ecbba370 mbs1/x86_64/apache-commons-fileupload-javadoc-1.2.2-7.1.mbs1.noarch.rpm 1c4c5c3bd6793c2a2450dcefa0e203ef mbs1/x86_64/maven-3.0.4-29.1.mbs1.noarch.rpm 8fc65ce434b39c1b4e99ac82c99f360c mbs1/x86_64/maven-javadoc-3.0.4-29.1.mbs1.noarch.rpm 690021e32ef08530eb6e0ffb37f183bb mbs1/x86_64/tomcat-7.0.41-1.mbs1.noarch.rpm ef37839b3c4cc68470895521b9c2f9b1 mbs1/x86_64/tomcat-admin-webapps-7.0.41-1.mbs1.noarch.rpm 10d70b5c2912cd31a3300cef68c8ae05 mbs1/x86_64/tomcat-docs-webapp-7.0.41-1.mbs1.noarch.rpm 30b9bce5753a84d5b297d09f325ee519 mbs1/x86_64/tomcat-el-2.2-api-7.0.41-1.mbs1.noarch.rpm 33f563c0129db18353f5f11ddff9da1f mbs1/x86_64/tomcat-javadoc-7.0.41-1.mbs1.noarch.rpm b695ab259ef3d94d7ff9d7080c133315 mbs1/x86_64/tomcat-jsp-2.2-api-7.0.41-1.mbs1.noarch.rpm 1a973a209c59818baaf9a702b127e4ce mbs1/x86_64/tomcat-jsvc-7.0.41-1.mbs1.noarch.rpm 2401f69cfd2a32b0cbfe08596e03b5af mbs1/x86_64/tomcat-lib-7.0.41-1.mbs1.noarch.rpm 4488a01e207711e525674516ba35166d mbs1/x86_64/tomcat-servlet-3.0-api-7.0.41-1.mbs1.noarch.rpm 8282439d68a86b4df5bb4a497fc355af mbs1/x86_64/tomcat-webapps-7.0.41-1.mbs1.noarch.rpm 0b2a663187d4e6f84842c8557c0aed88 mbs1/SRPMS/apache-commons-fileupload-1.2.2-7.1.mbs1.src.rpm 5838595a6d67a65a1b6ef7cf6010303b mbs1/SRPMS/maven-3.0.4-29.1.mbs1.src.rpm 2a1fe32885c43e8c24037d0d14411225 mbs1/SRPMS/tomcat-7.0.41-1.mbs1.src.rpm ___ To upgrade automatically use MandrivaUpdate or urpmi. The verification of md5 checksums and GPG signatures is performed automatically for you. All packages are signed by Mandriva for security. You can obtain the GPG public key of the Mandriva Security Team by executing: gpg --recv-keys --keyserver pgp.mit.edu 0x22458A98 You can view other update advisories for Mandriva Linux at: http://www.mandriva.com/en/support/security/advisories/ If you want to report vulnerabilities, please contact security_(at)_mandriva.com ___ Type Bits/KeyID Date User ID pub 1024D/22458A98 2000-07-10 Mandriva Security Team security*mandriva.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iD8DBQFTIXRwmqjQ0CJFipgRAmzFAKCuhe6bqDCVintv67zSlxhVksDmqQCg5il2 LQ4guSGikHcbr7VUIBHqsAM= =N5K+ -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] Capstone disassembly framework 2.1.1 released!
Greetings, We are glad to announce Capstone disassembly framework version 2.1.1! This stable release fixes some bugs deep in the core. There is no update to any architectures or bindings, so bindings version 2.1 can still be used with this version 2.1.1 just fine. Core changes: - Fix a buffer overflow bug in Thumb mode (ARM). - Fix a crash when embedding Capstone into OSX kernel. This should also enables Capstone to be embedded into other systems with similarly limited stack memory size such as Linux kernel or some firmwares. - Use a proper SONAME for library versioning (Linux). More information is available in our homepage at http://www.capstone-engine.org Thanks, Quynh ___ 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] [ MDVSA-2014:057 ] mediawiki
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ___ Mandriva Linux Security Advisory MDVSA-2014:057 http://www.mandriva.com/en/support/security/ ___ Package : mediawiki Date: March 13, 2014 Affected: Business Server 1.0 ___ Problem Description: Updated mediawiki packages fix multiple vulnerabilities: MediaWiki user Michael M reported that the fix for CVE-2013-4568 allowed insertion of escaped CSS values which could pass the CSS validation checks, resulting in XSS (CVE-2013-6451). Chris from RationalWiki reported that SVG files could be uploaded that include external stylesheets, which could lead to XSS when an XSL was used to include JavaScript (CVE-2013-6452). During internal review, it was discovered that MediaWiki#039;s SVG sanitization could be bypassed when the XML was considered invalid (CVE-2013-6453). During internal review, it was discovered that MediaWiki displayed some information about deleted pages in the log API, enhanced RecentChanges, and user watchlists (CVE-2013-6472). Netanel Rubin from Check Point discovered a remote code execution vulnerability in MediaWiki#039;s thumbnail generation for DjVu files. Internal review also discovered similar logic in the PdfHandler extension, which could be exploited in a similar way (CVE-2014-1610). MediaWiki before 1.22.3 does not block unsafe namespaces, such as a W3C XHTML namespace, in uploaded SVG files. Some client software may use these namespaces in a way that results in XSS. This was fixed by disallowing uploading SVG files using non-whitelisted namespaces (CVE-2014-2242). MediaWiki before 1.22.3 performs token comparison that may be vulnerable to timing attacks. This was fixed by making token comparison use constant time (CVE-2014-2243). MediaWiki before 1.22.3 could allow an attacker to perform XSS attacks, due to flaw with link handling in api.php. This was fixed such that it won#039;t find links in the middle of api.php links (CVE-2014-2244). MediaWiki has been updated to version 1.22.3, which fixes these issues, as well as several others. Also, the mediawiki-ldapauthentication and mediawiki-math extensions have been updated to newer versions that are compatible with MediaWiki 1.22. Additionally, the mediawiki-graphviz extension has been obsoleted, due to the fact that it is unmaintained upstream and is vulnerable to cross-site scripting attacks. Note: if you were using the instances feature in these packages to support multiple wiki instances, this feature has now been removed. You will need to maintain separate wiki instances manually. ___ References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-6451 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-6452 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-6453 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-6472 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-1610 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-2242 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-2243 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-2244 http://advisories.mageia.org/MGASA-2014-0113.html http://advisories.mageia.org/MGASA-2014-0124.html ___ Updated Packages: Mandriva Business Server 1/X86_64: 0763c6b913556fd3d098e14e6711d4c9 mbs1/x86_64/mediawiki-1.22.3-1.mbs1.noarch.rpm 3f3d638b7a09dfc700a56f06a0e06629 mbs1/x86_64/mediawiki-ldapauthentication-2.0f-1.mbs1.noarch.rpm c1bdd7ff8e5ab29f74891cb4fa92bff0 mbs1/x86_64/mediawiki-mysql-1.22.3-1.mbs1.noarch.rpm 6cd761769b330e837612ed079816019f mbs1/x86_64/mediawiki-pgsql-1.22.3-1.mbs1.noarch.rpm e484574d3776723c87e46a832daf3c4a mbs1/x86_64/mediawiki-sqlite-1.22.3-1.mbs1.noarch.rpm 870886ea628aaac381b4ab4210e33ea0 mbs1/SRPMS/mediawiki-1.22.3-1.mbs1.src.rpm bfbd6cc7fb3ce82be5c01564c5bfddde mbs1/SRPMS/mediawiki-ldapauthentication-2.0f-1.mbs1.src.rpm ___ To upgrade automatically use MandrivaUpdate or urpmi. The verification of md5 checksums and GPG signatures is performed automatically for you. All packages are signed by Mandriva for security. You can obtain the GPG public key of the Mandriva Security Team by executing: gpg --recv-keys --keyserver pgp.mit.edu 0x22458A98 You can view other update advisories for Mandriva Linux at: http://www.mandriva.com/en/support/security/advisories/ If you want to report vulnerabilities, please contact security_(at)_mandriva.com ___ Type Bits/KeyID
[Full-disclosure] [SECURITY] [DSA 2878-1] virtualbox security update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - - Debian Security Advisory DSA-2878-1 secur...@debian.org http://www.debian.org/security/Moritz Muehlenhoff March 13, 2014 http://www.debian.org/security/faq - - Package: virtualbox CVE ID : CVE-2013-5892 CVE-2014-0404 CVE-2014-0406 CVE-2014-0407 Debian Bug : 735410 Matthew Daley discovered multiple vulnerabilities in VirtualBox, a x86 virtualisation solution, resulting in denial of service, privilege escalation and an information leak. For the oldstable distribution (squeeze), these problems have been fixed in version 3.2.10-dfsg-1+squeeze2 of the virtualbox-ose source package. For the stable distribution (wheezy), these problems have been fixed in version 4.1.18-dfsg-2+deb7u2. For the testing distribution (jessie), these problems have been fixed in version 4.3.6-dfsg-1. For the unstable distribution (sid), these problems have been fixed in version 4.3.6-dfsg-1. We recommend that you upgrade your virtualbox packages. Further information about Debian Security Advisories, how to apply these updates to your system and frequently asked questions can be found at: http://www.debian.org/security/ Mailing list: debian-security-annou...@lists.debian.org -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJTIcvtAAoJEBDCk7bDfE42e/kQAIL6all431PYZuXa4JK5MctA cQfqs5Zh+Q8FaEl3s0mrly4qAiV26m1/9irSL1jcW8TgWe5CpQFoEqUFLqDTDwEO KDVo0JzKJNp+3egopoGZ4jsSu1qu716fj7BKLrpQZflGrXNnKeOU4S3ssz1IjluQ N+goKvrbFZyHTY/vYPhVHoIQxDN7ZaK1G2KWzVgJV2iS4a8IY+jMdGEc5/ICVnfq La0/EokIZ3JskCwV50SEaVV4XI7a4GkpjLX9+RwfEkZ6OXaZ8NrLAQtuBRCD4RyP LhFqtVORBTpXy4hS9VCWjjjr0jJV3wx2nNmRPE5a7Nnrj1YYEoMcDqc/nL4mH721 0Fwe64L/T1FVmiijXszX4sqKA6OvDiP++uPfWWpMg6F24gmC29YkrHmX8ktI/5I1 87XeeFDHdn9xuSCMRddl0Oztw+0iDR6+UXtgTz896k331p5FYE05W4S/U0vDGSHV BSE//pgJJgHjboGAZpvhNS3qPKb/AGxAxfqxJjiAqMrgObddqd6pZpRDWPOG1HOh bVVffFHbjbVwkcPKIZey3PSbhv9v+pBUx/4Wq/3FgVIr+X3PGwSMm7FLP49m+nbi vT/rF9FCDgxJELKfelygrzYavi52O80XU4xOdhDCpwRRTxy72Jh3GwwG/dgAtj68 joj53dPlRUpBp+TNpie1 =y9Jn -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] [ MDVSA-2014:058 ] freeradius
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ___ Mandriva Linux Security Advisory MDVSA-2014:058 http://www.mandriva.com/en/support/security/ ___ Package : freeradius Date: March 13, 2014 Affected: Business Server 1.0, Enterprise Server 5.0 ___ Problem Description: Updated freeradius package fixes security vulnerability: SSHA processing in freeradius before 2.2.3 runs into a stack-based buffer overflow in the freeradius rlm_pap module if the password source uses an unusually long hashed password (CVE-2014-2015). ___ References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-2015 http://advisories.mageia.org/MGASA-2014-0088.html ___ Updated Packages: Mandriva Enterprise Server 5: ad944c9074b82a96e5bca829cb9e53a6 mes5/i586/freeradius-2.1.0-3.2mdvmes5.2.i586.rpm a99e3e6e10a0856e4d755d17653865a0 mes5/i586/freeradius-krb5-2.1.0-3.2mdvmes5.2.i586.rpm 322a9c4b628cf1e94263c060b6978fde mes5/i586/freeradius-ldap-2.1.0-3.2mdvmes5.2.i586.rpm e554bcf6daa40436f85ad06b4bc4a81a mes5/i586/freeradius-mysql-2.1.0-3.2mdvmes5.2.i586.rpm 95588e3bdf6cf1f1711416c1966a5683 mes5/i586/freeradius-postgresql-2.1.0-3.2mdvmes5.2.i586.rpm e998de66a546e5f1c325a1aae720ce8d mes5/i586/freeradius-unixODBC-2.1.0-3.2mdvmes5.2.i586.rpm 92cc08607f5a1db4b8181f3fa1f882ac mes5/i586/freeradius-web-2.1.0-3.2mdvmes5.2.i586.rpm 59efbacd16cd43b769194eebd86b9aa8 mes5/i586/libfreeradius1-2.1.0-3.2mdvmes5.2.i586.rpm c22ae710c958e08cd230f90b4a8dd02d mes5/i586/libfreeradius-devel-2.1.0-3.2mdvmes5.2.i586.rpm cc1524d78d985dcfe1cc52e0c4167c53 mes5/SRPMS/freeradius-2.1.0-3.2mdvmes5.2.src.rpm Mandriva Enterprise Server 5/X86_64: 56840a173c160cba06a7fb7c80ddb64f mes5/x86_64/freeradius-2.1.0-3.2mdvmes5.2.x86_64.rpm 0941ddc851295f4925de5f583da68475 mes5/x86_64/freeradius-krb5-2.1.0-3.2mdvmes5.2.x86_64.rpm e4af5670c6cab9b67add4e70aed3b684 mes5/x86_64/freeradius-ldap-2.1.0-3.2mdvmes5.2.x86_64.rpm 25df0aba6eee4288d21ecda61c30b778 mes5/x86_64/freeradius-mysql-2.1.0-3.2mdvmes5.2.x86_64.rpm b9ccf0bc86cdc0b3cd05bfa4fabacf2a mes5/x86_64/freeradius-postgresql-2.1.0-3.2mdvmes5.2.x86_64.rpm 7826a0387961c9d212be1532f2455664 mes5/x86_64/freeradius-unixODBC-2.1.0-3.2mdvmes5.2.x86_64.rpm d20ac56207ef50426beaea46e1196c63 mes5/x86_64/freeradius-web-2.1.0-3.2mdvmes5.2.x86_64.rpm 1dad7dd1a4b40a99c21edc8598b7aeea mes5/x86_64/lib64freeradius1-2.1.0-3.2mdvmes5.2.x86_64.rpm 047d0222be6c58c6757fb63c4489e91e mes5/x86_64/lib64freeradius-devel-2.1.0-3.2mdvmes5.2.x86_64.rpm cc1524d78d985dcfe1cc52e0c4167c53 mes5/SRPMS/freeradius-2.1.0-3.2mdvmes5.2.src.rpm Mandriva Business Server 1/X86_64: 0057f36548b76ab4309513af32189a7a mbs1/x86_64/freeradius-2.1.12-9.2.mbs1.x86_64.rpm bf926a73a78b4d71ed289882174faff0 mbs1/x86_64/freeradius-krb5-2.1.12-9.2.mbs1.x86_64.rpm 2a4d779f740e148179a2fa47f6b5d11a mbs1/x86_64/freeradius-ldap-2.1.12-9.2.mbs1.x86_64.rpm 6194d14adfb3a1be7098d6a80c68666c mbs1/x86_64/freeradius-mysql-2.1.12-9.2.mbs1.x86_64.rpm aa9d2789f6ba9ef13ddcbd8f1401053b mbs1/x86_64/freeradius-postgresql-2.1.12-9.2.mbs1.x86_64.rpm dced45a8d3116fda640cbf87a92045d9 mbs1/x86_64/freeradius-sqlite-2.1.12-9.2.mbs1.x86_64.rpm 6334b8e46550b4386845e965de3ddd6e mbs1/x86_64/freeradius-unixODBC-2.1.12-9.2.mbs1.x86_64.rpm 7c50512bed1debd14c01ac39a23664a0 mbs1/x86_64/freeradius-web-2.1.12-9.2.mbs1.x86_64.rpm 180924551409613494f9d37e171981bd mbs1/x86_64/lib64freeradius1-2.1.12-9.2.mbs1.x86_64.rpm aa658a202d8dfa5d34126b548206afb9 mbs1/x86_64/lib64freeradius-devel-2.1.12-9.2.mbs1.x86_64.rpm d71925925b1416ea729b8b85c7f0919c mbs1/SRPMS/freeradius-2.1.12-9.2.mbs1.src.rpm ___ To upgrade automatically use MandrivaUpdate or urpmi. The verification of md5 checksums and GPG signatures is performed automatically for you. All packages are signed by Mandriva for security. You can obtain the GPG public key of the Mandriva Security Team by executing: gpg --recv-keys --keyserver pgp.mit.edu 0x22458A98 You can view other update advisories for Mandriva Linux at: http://www.mandriva.com/en/support/security/advisories/ If you want to report vulnerabilities, please contact security_(at)_mandriva.com ___ Type Bits/KeyID Date User ID pub 1024D/22458A98 2000-07-10 Mandriva Security Team security*mandriva.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iD8DBQFTIaX3mqjQ0CJFipgRAmfrAJ4+2PFcRArhKtgBxVFMRghXs3mB+QCfQNcE KMIx0VlhDi+BX+cm21ZnGgQ= =MBcL
Re: [Full-disclosure] Google vulnerabilities with PoC
I think Adam was right replying that way, so that it's not a security bug. You haven't found anything exploitable. The only reasonable way to 'exploit' the bug is using youtube as a personal storage uploading non-video files to your own profile: so what? It's like saying that you have a normal file upload functionality in a PHP application on Apache that expects files with extension .png only, and you manage to upload an .asp file. Security-wise that's not a risk. Cheers antisnatchor Nicholas Lemonias. wrote: Google vulnerabilities uncovered... http://news.softpedia.com/news/Expert-Finds-File-Upload-Vulnerability-in-YouTube-Google-Denies-It-s-a-Security-Issue-431489.shtml ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ -- Cheers Michele ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Google vulnerabilities with PoC
The only reasonable way to 'exploit' the bug is using youtube as a personal storage uploading non-video files to your own profile: so what? That would require a way to retrieve the stored data, which - as I understand - isn't possible here (although the report seems a bit hard-to-parse). From what I recall, you can just upload a blob of data and essentially see it disappear. We do have quite a few services where you can legitimately upload and share nearly-arbitrary content, though. Google Drive is a good example. /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Google vulnerabilities with PoC
If you were evil, you could upload huge blobs and just take up space on the google servers. Who knows what will happen if you upload a couple hundred gigs of files. They dont disappear, they are just unretrievable afaict. It is a security risk in the sense that untrusted data is being persisted *somewhere*. Upload a couple terabytes, cause a DoS because some hdd in the DC fills up. Who knows. Sent from a computer On Mar 13, 2014, at 12:28 PM, Michal Zalewski lcam...@coredump.cx wrote: The only reasonable way to 'exploit' the bug is using youtube as a personal storage uploading non-video files to your own profile: so what? That would require a way to retrieve the stored data, which - as I understand - isn't possible here (although the report seems a bit hard-to-parse). From what I recall, you can just upload a blob of data and essentially see it disappear. We do have quite a few services where you can legitimately upload and share nearly-arbitrary content, though. Google Drive is a good example. /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Google vulnerabilities with PoC
If you were evil, you could upload huge blobs and just take up space on the google servers. Keep in mind that the upload functionality is there legitimately: you can upload gigabytes of data to Youtube, Drive, Gmail, etc. /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Google vulnerabilities with PoC
: you could upload huge blobs and just take up space on the google servers. How many people upload gigabytes of crappy videos on google servers, hourly? So far, the DDoS didn't happen for some reason, even considering the amount of users. There is a small potential to exploit this via a botnet, but what's the gain? YT upload breaks? Wow, so much win. By the way, why not just upload some valid, generated on the fly MPEG stream? The effect is the same if you consider the data amount, but without all the unrestricted shouts and academic vulnerabilities. 2014-03-13 18:33 GMT+01:00 Brandon Perry bperry.volat...@gmail.com: If you were evil, you could upload huge blobs and just take up space on the google servers. Who knows what will happen if you upload a couple hundred gigs of files. They dont disappear, they are just unretrievable afaict. It is a security risk in the sense that untrusted data is being persisted *somewhere*. Upload a couple terabytes, cause a DoS because some hdd in the DC fills up. Who knows. Sent from a computer On Mar 13, 2014, at 12:28 PM, Michal Zalewski lcam...@coredump.cx wrote: The only reasonable way to 'exploit' the bug is using youtube as a personal storage uploading non-video files to your own profile: so what? That would require a way to retrieve the stored data, which - as I understand - isn't possible here (although the report seems a bit hard-to-parse). From what I recall, you can just upload a blob of data and essentially see it disappear. We do have quite a few services where you can legitimately upload and share nearly-arbitrary content, though. Google Drive is a good example. /mz ___ 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 - http://secunia.com/
Re: [Full-disclosure] Google vulnerabilities with PoC
Yes, these are legitimate points. Sent from a computer On Mar 13, 2014, at 12:43 PM, Źmicier Januszkiewicz ga...@tut.by wrote: : you could upload huge blobs and just take up space on the google servers. How many people upload gigabytes of crappy videos on google servers, hourly? So far, the DDoS didn't happen for some reason, even considering the amount of users. There is a small potential to exploit this via a botnet, but what's the gain? YT upload breaks? Wow, so much win. By the way, why not just upload some valid, generated on the fly MPEG stream? The effect is the same if you consider the data amount, but without all the unrestricted shouts and academic vulnerabilities. 2014-03-13 18:33 GMT+01:00 Brandon Perry bperry.volat...@gmail.com: If you were evil, you could upload huge blobs and just take up space on the google servers. Who knows what will happen if you upload a couple hundred gigs of files. They dont disappear, they are just unretrievable afaict. It is a security risk in the sense that untrusted data is being persisted *somewhere*. Upload a couple terabytes, cause a DoS because some hdd in the DC fills up. Who knows. Sent from a computer On Mar 13, 2014, at 12:28 PM, Michal Zalewski lcam...@coredump.cx wrote: The only reasonable way to 'exploit' the bug is using youtube as a personal storage uploading non-video files to your own profile: so what? That would require a way to retrieve the stored data, which - as I understand - isn't possible here (although the report seems a bit hard-to-parse). From what I recall, you can just upload a blob of data and essentially see it disappear. We do have quite a few services where you can legitimately upload and share nearly-arbitrary content, though. Google Drive is a good example. /mz ___ 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 - http://secunia.com/
[Full-disclosure] CarolinaCon-10 - May 2014 - FINAL ANNOUNCEMENT
CarolinaCon-10 will be held on May 16th-18th, 2014 in Raleigh NC. For the cheap price of your average movie admission with popcorn and a drink ($20) YOU could get a full weekend of talks, hacks, contests, and parties. We've selected as many presentations as we can fit into the lineup. Here they are, in no particular order: - Bypassing EMET 4.1 - Jared DeMott - Password Cracking for noobs - smrk3r - AV Evasion with the Veil Framework - HarmJ0y, Christopher Truncer, Michael Wright - Simple Network Management Pwnd - Deral Heiland Matthew Kienow - F*ck These Guys: Practical Counter-surveillance - Lisa Lorenzin - Carding Markets: Comparing Apples and Lemons - Professor Tom Holt - Exploiting the Bells and Whistles: Uncovering OEM Vulnerabilities in Android - Jake Valletta - How To Get Money Fast Using A Pwned PBX - unregistered436 - MDM is gone, MAM is coming - Yury Chemerkin - Demystifying The Cloud, a look at Hyperscale Computing From a Hacker Perspective - Nick Fury - The Insider Threat: From Snowden to the Unspoken - Omar Santos - Reverse Engineering Executables - Math 400 - Armageddon In The Air - Guarav Raj Anand - Hack Android Using Normal Permissions Broadcast Receivers - Fadi Mohsen - Exceptions In Java Frameworks That Will Get You Owned - Benjamin Watson - Attacker Ghost Stories: Mostly Free Defenses That Gives Attackers Nightmares - mubix - Hacking the Hackerspace - Steven Sutton and Alan Fay **and possibly another presentation, plus another possible surprise yet to be locked-in** CarolinaCon-10 Contests/Challenges: - Capture The Flag - Hacker Trivia - Crypto Challenge (TBD) Other CarolinaCon-10 Side Events: - Lockpicking Village / Instruction - Saturday Night Hacker Social LODGING: If you're traveling and wish to stay at the Con hotel here is the direct link to the special CarolinaCon discount group rate ($101, set by the Hilton, not us): http://www.hilton.com/en/hi/groups/personalized/R/RDUNHHF-CCC-20140515/index.jhtml Shorter reservation link version: http://bit.ly/1cdpzjU ATTENTION: The discount group rate on Hilton hotel rooms expires on APRIL 18th 2014, so act quickly if you plan on staying at the hotel for all of the weekend fun. ADVERTISERS / VENDORS / SPONSORS: There are no advertisers, vendors, or sponsors allowed at CarolinaConever. Please don't waste your time or ours in asking. However if you have some spare non-commercial SWAG that you'd care to charitably donate as contest prizes we will always accept that with great appreciation. Contact us via: infoatcarolinacon.org CarolinaCon formal proceedings/talks will run; - 7pm to 11pm on Friday - 10am to 9pm on Saturday - 10am to 4pm on Sunday For presentation abstracts, speaker bios, the final schedule, side event information, and all the other exciting details (as they develop and as our webmaster gets to them) stay tuned to; http://www.carolinacon.org CarolinaCon has been Rated M for Mature. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Google vulnerabilities with PoC
On Mar 13, 2014, at 10:33, Brandon Perry bperry.volat...@gmail.com wrote: If you were evil, you could upload huge blobs and just take up space on the google servers. Who knows what will happen if you upload a couple hundred gigs of files. They dont disappear, they are just unretrievable afaict. It is a security risk in the sense that untrusted data is being persisted *somewhere*. It's not even clear at this point that the uploaded data is even being persisted! Since the uploaded file is not made available for download, it's entirely possible that it is being deleted as soon as Google's video transcoding systems discover it isn't a supported video format. The comments on the Softpedia article are painfully stupid, by the way. I recommend not reading them. :) ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Google vulnerabilities with PoC
When did the ability to upload files of arbitrary types become a security issue? If the file doesn't get executed, it's really not a problem. (Besides from potentially breaking site layout standpoint.) 2014-03-13 12:43 GMT+02:00 Nicholas Lemonias. lem.niko...@googlemail.com: Google vulnerabilities uncovered... http://news.softpedia.com/news/Expert-Finds-File-Upload-Vulnerability-in-YouTube-Google-Denies-It-s-a-Security-Issue-431489.shtml ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Google vulnerabilities with PoC
Keep in mind that YouTube allows files to be uploaded by definition. What you have achieved is upload a file for an extension type that is not allowed. It is definitely a vulnerability but a low risk one since you haven't demonstrated if it has any ill effects. Can you somehow find the URL to where the file was uploaded? I would guess not, since a well designed service like YouTube should hide those details and no leak them in any way. Maybe if you are able to find that you can combine with this vulnerability and get them to open their wallet? Regards Pedro On 13 Mar 2014 11:50, Nicholas Lemonias. lem.niko...@googlemail.com wrote: Google vulnerabilities uncovered... http://news.softpedia.com/news/Expert-Finds-File-Upload-Vulnerability-in-YouTube-Google-Denies-It-s-a-Security-Issue-431489.shtml ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Google vulnerabilities with PoC
Here is your answer. https://www.owasp.org/index.php/Unrestricted_File_Upload On Thu, Mar 13, 2014 at 1:39 PM, Julius Kivimäki julius.kivim...@gmail.comwrote: When did the ability to upload files of arbitrary types become a security issue? If the file doesn't get executed, it's really not a problem. (Besides from potentially breaking site layout standpoint.) 2014-03-13 12:43 GMT+02:00 Nicholas Lemonias. lem.niko...@googlemail.com : Google vulnerabilities uncovered... http://news.softpedia.com/news/Expert-Finds-File-Upload-Vulnerability-in-YouTube-Google-Denies-It-s-a-Security-Issue-431489.shtml ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Google vulnerabilities with PoC
*https://www.google.com/settings/takeout https://www.google.com/settings/takeout * *However the only problem would be to get past Content ID filtering. I suppose encrypting an uploaded file, and obfuscating file headers may get past YouTube's Content ID filtering. Youtube is not a File Transfer Protocol... It's there to serve media content. * https://www.google.gr/# On Thu, Mar 13, 2014 at 1:52 PM, Pedro Ribeiro ped...@gmail.com wrote: Keep in mind that YouTube allows files to be uploaded by definition. What you have achieved is upload a file for an extension type that is not allowed. It is definitely a vulnerability but a low risk one since you haven't demonstrated if it has any ill effects. Can you somehow find the URL to where the file was uploaded? I would guess not, since a well designed service like YouTube should hide those details and no leak them in any way. Maybe if you are able to find that you can combine with this vulnerability and get them to open their wallet? Regards Pedro On 13 Mar 2014 11:50, Nicholas Lemonias. lem.niko...@googlemail.com wrote: Google vulnerabilities uncovered... http://news.softpedia.com/news/Expert-Finds-File-Upload-Vulnerability-in-YouTube-Google-Denies-It-s-a-Security-Issue-431489.shtml ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Google vulnerabilities with PoC
I suggest you to read on Content Delivery Network Architectures . YouTube.com populates and distributes stored files to multiple servers through a CDN (Content Delivery Architecture), where each video uses more than one machine (hosted by a cluster). Less populated video files are normally stored in various colocation sites. The YouTube architecture uses databases for storing metadata information of all uploaded files. https://www.owasp.org/index.php/Unrestricted_File_Upload On Thu, Mar 13, 2014 at 2:22 PM, Nicholas Lemonias. lem.niko...@googlemail.com wrote: *https://www.google.com/settings/takeout https://www.google.com/settings/takeout * *However the only problem would be to get past Content ID filtering. I suppose encrypting an uploaded file, and obfuscating file headers may get past YouTube's Content ID filtering. Youtube is not a File Transfer Protocol... It's there to serve media content. * https://www.google.gr/# On Thu, Mar 13, 2014 at 1:52 PM, Pedro Ribeiro ped...@gmail.com wrote: Keep in mind that YouTube allows files to be uploaded by definition. What you have achieved is upload a file for an extension type that is not allowed. It is definitely a vulnerability but a low risk one since you haven't demonstrated if it has any ill effects. Can you somehow find the URL to where the file was uploaded? I would guess not, since a well designed service like YouTube should hide those details and no leak them in any way. Maybe if you are able to find that you can combine with this vulnerability and get them to open their wallet? Regards Pedro On 13 Mar 2014 11:50, Nicholas Lemonias. lem.niko...@googlemail.com wrote: Google vulnerabilities uncovered... http://news.softpedia.com/news/Expert-Finds-File-Upload-Vulnerability-in-YouTube-Google-Denies-It-s-a-Security-Issue-431489.shtml ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Google vulnerabilities with PoC
Did you even read that article? (Not that OWASP has any sort of credibility anyways). From what I saw in your previous post you are both unable to execute the files or even access them and thus unable to manipulate the content-type the files are returned with, therefore there is no vulnerability (According to the article you linked.). BTW, you should look for more cool vulnerabilities in amazons EC2, I'm sure you will find some Unrestricted File Upload holes. 2014-03-13 16:18 GMT+02:00 Nicholas Lemonias. lem.niko...@googlemail.com: Here is your answer. https://www.owasp.org/index.php/Unrestricted_File_Upload On Thu, Mar 13, 2014 at 1:39 PM, Julius Kivimäki julius.kivim...@gmail.com wrote: When did the ability to upload files of arbitrary types become a security issue? If the file doesn't get executed, it's really not a problem. (Besides from potentially breaking site layout standpoint.) 2014-03-13 12:43 GMT+02:00 Nicholas Lemonias. lem.niko...@googlemail.com : Google vulnerabilities uncovered... http://news.softpedia.com/news/Expert-Finds-File-Upload-Vulnerability-in-YouTube-Google-Denies-It-s-a-Security-Issue-431489.shtml ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Google vulnerabilities with PoC
*You are wrong about accessing the files. What has not been confirmed is remote code execution. We are working on it.* *And please, OWASP is recognised worldwide... * *Files can be accessed through Google Take out with a little bit of skills.* *https://www.google.com/settings/takeout https://www.google.com/settings/takeout * On Thu, Mar 13, 2014 at 4:09 PM, Julius Kivimäki julius.kivim...@gmail.comwrote: Did you even read that article? (Not that OWASP has any sort of credibility anyways). From what I saw in your previous post you are both unable to execute the files or even access them and thus unable to manipulate the content-type the files are returned with, therefore there is no vulnerability (According to the article you linked.). BTW, you should look for more cool vulnerabilities in amazons EC2, I'm sure you will find some Unrestricted File Upload holes. 2014-03-13 16:18 GMT+02:00 Nicholas Lemonias. lem.niko...@googlemail.com : Here is your answer. https://www.owasp.org/index.php/Unrestricted_File_Upload On Thu, Mar 13, 2014 at 1:39 PM, Julius Kivimäki julius.kivim...@gmail.com wrote: When did the ability to upload files of arbitrary types become a security issue? If the file doesn't get executed, it's really not a problem. (Besides from potentially breaking site layout standpoint.) 2014-03-13 12:43 GMT+02:00 Nicholas Lemonias. lem.niko...@googlemail.com: Google vulnerabilities uncovered... http://news.softpedia.com/news/Expert-Finds-File-Upload-Vulnerability-in-YouTube-Google-Denies-It-s-a-Security-Issue-431489.shtml ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Google vulnerabilities with PoC
OWASP is recognized worldwide, so is CEH and a bunch of other morons. That doesn't mean their publications are worth anything. Now tell me, why would arbitrary file upload on a CDN lead to code execution (Besides for HTML, which you have been unable to confirm)? 2014-03-13 18:16 GMT+02:00 Nicholas Lemonias. lem.niko...@googlemail.com: *You are wrong about accessing the files. What has not been confirmed is remote code execution. We are working on it.* *And please, OWASP is recognised worldwide... * *Files can be accessed through Google Take out with a little bit of skills.* *https://www.google.com/settings/takeout https://www.google.com/settings/takeout * On Thu, Mar 13, 2014 at 4:09 PM, Julius Kivimäki julius.kivim...@gmail.com wrote: Did you even read that article? (Not that OWASP has any sort of credibility anyways). From what I saw in your previous post you are both unable to execute the files or even access them and thus unable to manipulate the content-type the files are returned with, therefore there is no vulnerability (According to the article you linked.). BTW, you should look for more cool vulnerabilities in amazons EC2, I'm sure you will find some Unrestricted File Upload holes. 2014-03-13 16:18 GMT+02:00 Nicholas Lemonias. lem.niko...@googlemail.com : Here is your answer. https://www.owasp.org/index.php/Unrestricted_File_Upload On Thu, Mar 13, 2014 at 1:39 PM, Julius Kivimäki julius.kivim...@gmail.com wrote: When did the ability to upload files of arbitrary types become a security issue? If the file doesn't get executed, it's really not a problem. (Besides from potentially breaking site layout standpoint.) 2014-03-13 12:43 GMT+02:00 Nicholas Lemonias. lem.niko...@googlemail.com: Google vulnerabilities uncovered... http://news.softpedia.com/news/Expert-Finds-File-Upload-Vulnerability-in-YouTube-Google-Denies-It-s-a-Security-Issue-431489.shtml ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Google vulnerabilities with PoC
Hello Julius, I appreciate your interest to learn more. OWASP is quite credible, and has gained some international recognition. It is a benchmark for many vendors. I suggest you to read on OSI/7-Layer Model. A website may disallow uploads of certain file types for security reasons, and let's assume at the application layer. If we manage to get past the security controls, that means we can write unrestrictedly any type of file to the remote network. That also means that we get past their firewall, since the communication is through HTTP (port 80). CDN nodes are deployed to multiple colocation (thousands of nodes and thousands of servers across the world). The files (let's say a self-executing encrypted virus like Cryptolocker? ) are cached deeply in the network across thousands of servers. On Thu, Mar 13, 2014 at 5:07 PM, Nicholas Lemonias. lem.niko...@googlemail.com wrote: Hello Julius, I appreciate your interest to learn more. OWASP is quite credible, and has gained some international recognition. It is a benchmark for many vendors. I suggest you to read on OSI/7-Layer Model. A website may disallow uploads of certain file types for security reasons, and let's assume at the application layer. If we manage to get past the security controls, that means we can write unrestrictedly any type of file to the remote network. That also means that we get past their firewall, since the communication is through HTTP (port 80). CDN nodes are deployed to multiple colocation (thousands of nodes and thousands of servers across the world). The files are cached deep in the network structures to thousands of servers. On Thu, Mar 13, 2014 at 4:20 PM, Julius Kivimäki julius.kivim...@gmail.com wrote: OWASP is recognized worldwide, so is CEH and a bunch of other morons. That doesn't mean their publications are worth anything. Now tell me, why would arbitrary file upload on a CDN lead to code execution (Besides for HTML, which you have been unable to confirm)? 2014-03-13 18:16 GMT+02:00 Nicholas Lemonias. lem.niko...@googlemail.com : *You are wrong about accessing the files. What has not been confirmed is remote code execution. We are working on it.* *And please, OWASP is recognised worldwide... * *Files can be accessed through Google Take out with a little bit of skills.* *https://www.google.com/settings/takeout https://www.google.com/settings/takeout * On Thu, Mar 13, 2014 at 4:09 PM, Julius Kivimäki julius.kivim...@gmail.com wrote: Did you even read that article? (Not that OWASP has any sort of credibility anyways). From what I saw in your previous post you are both unable to execute the files or even access them and thus unable to manipulate the content-type the files are returned with, therefore there is no vulnerability (According to the article you linked.). BTW, you should look for more cool vulnerabilities in amazons EC2, I'm sure you will find some Unrestricted File Upload holes. 2014-03-13 16:18 GMT+02:00 Nicholas Lemonias. lem.niko...@googlemail.com: Here is your answer. https://www.owasp.org/index.php/Unrestricted_File_Upload On Thu, Mar 13, 2014 at 1:39 PM, Julius Kivimäki julius.kivim...@gmail.com wrote: When did the ability to upload files of arbitrary types become a security issue? If the file doesn't get executed, it's really not a problem. (Besides from potentially breaking site layout standpoint.) 2014-03-13 12:43 GMT+02:00 Nicholas Lemonias. lem.niko...@googlemail.com: Google vulnerabilities uncovered... http://news.softpedia.com/news/Expert-Finds-File-Upload-Vulnerability-in-YouTube-Google-Denies-It-s-a-Security-Issue-431489.shtml ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Google vulnerabilities with PoC
hahahaha you also could send emails to yourself untill fill up the google storages. of course its not a security issue. On Thu, Mar 13, 2014 at 2:33 PM, Brandon Perry bperry.volat...@gmail.comwrote: If you were evil, you could upload huge blobs and just take up space on the google servers. Who knows what will happen if you upload a couple hundred gigs of files. They dont disappear, they are just unretrievable afaict. It is a security risk in the sense that untrusted data is being persisted *somewhere*. Upload a couple terabytes, cause a DoS because some hdd in the DC fills up. Who knows. Sent from a computer On Mar 13, 2014, at 12:28 PM, Michal Zalewski lcam...@coredump.cx wrote: The only reasonable way to 'exploit' the bug is using youtube as a personal storage uploading non-video files to your own profile: so what? That would require a way to retrieve the stored data, which - as I understand - isn't possible here (although the report seems a bit hard-to-parse). From what I recall, you can just upload a blob of data and essentially see it disappear. We do have quite a few services where you can legitimately upload and share nearly-arbitrary content, though. Google Drive is a good example. /mz ___ 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/ -- Grato, J. Tozo _ °v° /(S)\SLACKWARE ^ ^ Linux _ because it works ___ 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] ActiVPN launches its security bug bounty
ActiVPN launches its security bug bounty. Please check the latest terms and contact details, as they may get updated: http://activpn.com/en/security/ Excerpt: If you believe that you find a vulnerability in http://activpn.com or the ActiVPN infrastructure, let's talk. We will remunerate you depending on the impact of the vulnerability and the creativity of the exploitation technique. The remuneration amount is at our own discretion. There is no maximum reward. - OK: Code Execution at server side: BOF, UAF in our server applications - OK: Web Command Injection: Shell Injection, XSS, SQL Injection, PHP injection ... - OK: open redirect - OK: authentication or authorization flaw, or significant infoleak of customer data - Responsible disclosure only: never publish any user data, do not publish the details of the vulnerability before it has been patched - Responsible behavior only: if you gain write access, do not modify or delete other users' data, use accounts you created for this purpose ; similarly, if you gain read access, do not dump the whole dataset, two entries you created are enough. - scope: *.activpn.com - EXCLUDED: DDOS, Spam, Phishing, logout CSRF, ClickJacking Cheers, http://activpn.com/en/security/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Google vulnerabilities with PoC
I don't see what OSI model has to do with anything here. Why is arbitrary file upload to youtube CDN any worse than to google drive CDN? And how will your self-executing encrypted virus like Cryptolocker end up getting executed anyways? And cryptolocker was definitely not self-executing, but spread via email attachments (excluding the boring USB spread functionality). What you have here is not a vulnerability, just give up. And stop trying to get journalists like Eduard Kovacs to spread your BS. 2014-03-13 19:10 GMT+02:00 Nicholas Lemonias. lem.niko...@googlemail.com: Hello Julius, I appreciate your interest to learn more. OWASP is quite credible, and has gained some international recognition. It is a benchmark for many vendors. I suggest you to read on OSI/7-Layer Model. A website may disallow uploads of certain file types for security reasons, and let's assume at the application layer. If we manage to get past the security controls, that means we can write unrestrictedly any type of file to the remote network. That also means that we get past their firewall, since the communication is through HTTP (port 80). CDN nodes are deployed to multiple colocation (thousands of nodes and thousands of servers across the world). The files (let's say a self-executing encrypted virus like Cryptolocker? ) are cached deeply in the network across thousands of servers. On Thu, Mar 13, 2014 at 5:07 PM, Nicholas Lemonias. lem.niko...@googlemail.com wrote: Hello Julius, I appreciate your interest to learn more. OWASP is quite credible, and has gained some international recognition. It is a benchmark for many vendors. I suggest you to read on OSI/7-Layer Model. A website may disallow uploads of certain file types for security reasons, and let's assume at the application layer. If we manage to get past the security controls, that means we can write unrestrictedly any type of file to the remote network. That also means that we get past their firewall, since the communication is through HTTP (port 80). CDN nodes are deployed to multiple colocation (thousands of nodes and thousands of servers across the world). The files are cached deep in the network structures to thousands of servers. On Thu, Mar 13, 2014 at 4:20 PM, Julius Kivimäki julius.kivim...@gmail.com wrote: OWASP is recognized worldwide, so is CEH and a bunch of other morons. That doesn't mean their publications are worth anything. Now tell me, why would arbitrary file upload on a CDN lead to code execution (Besides for HTML, which you have been unable to confirm)? 2014-03-13 18:16 GMT+02:00 Nicholas Lemonias. lem.niko...@googlemail.com: *You are wrong about accessing the files. What has not been confirmed is remote code execution. We are working on it.* *And please, OWASP is recognised worldwide... * *Files can be accessed through Google Take out with a little bit of skills.* *https://www.google.com/settings/takeout https://www.google.com/settings/takeout * On Thu, Mar 13, 2014 at 4:09 PM, Julius Kivimäki julius.kivim...@gmail.com wrote: Did you even read that article? (Not that OWASP has any sort of credibility anyways). From what I saw in your previous post you are both unable to execute the files or even access them and thus unable to manipulate the content-type the files are returned with, therefore there is no vulnerability (According to the article you linked.). BTW, you should look for more cool vulnerabilities in amazons EC2, I'm sure you will find some Unrestricted File Upload holes. 2014-03-13 16:18 GMT+02:00 Nicholas Lemonias. lem.niko...@googlemail.com: Here is your answer. https://www.owasp.org/index.php/Unrestricted_File_Upload On Thu, Mar 13, 2014 at 1:39 PM, Julius Kivimäki julius.kivim...@gmail.com wrote: When did the ability to upload files of arbitrary types become a security issue? If the file doesn't get executed, it's really not a problem. (Besides from potentially breaking site layout standpoint.) 2014-03-13 12:43 GMT+02:00 Nicholas Lemonias. lem.niko...@googlemail.com: Google vulnerabilities uncovered... http://news.softpedia.com/news/Expert-Finds-File-Upload-Vulnerability-in-YouTube-Google-Denies-It-s-a-Security-Issue-431489.shtml ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Google vulnerabilities with PoC
So in terms of permissions. What's the different between admin.youtube.comand a normal youtube user? I assume that the admin has a full permission set. If that's the case, that means it is a valid vulnerability for the reason being that the integrity of the service is impacted. The youtube user circumvents the design and gets arbitrary write (w) permissions of any file-type. (The access control matrix is bypassed here) Since YouTube by design is not an FTP Service, and even Google drive is a paid service - Then yes it is a vulnerability. Why are you guys looking for impact elsewhere? The impact is to the integrity of the service - arbitrary write permissions. On Thu, Mar 13, 2014 at 5:28 PM, Michal Zalewski lcam...@coredump.cxwrote: The only reasonable way to 'exploit' the bug is using youtube as a personal storage uploading non-video files to your own profile: so what? That would require a way to retrieve the stored data, which - as I understand - isn't possible here (although the report seems a bit hard-to-parse). From what I recall, you can just upload a blob of data and essentially see it disappear. We do have quite a few services where you can legitimately upload and share nearly-arbitrary content, though. Google Drive is a good example. /mz ___ 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] Fwd: Google vulnerabilities with PoC
Julius Kivimaki, your disbelief in OWASP, CEH, Journalists and anything you may, or may not be qualified to question amazes. But everyone's opinion is of course respected. I normally don't provide security lessons via e-mail and full-disclosure, however you seem not to understand the security report fully and some core principles. If you can't see what information security best practises, the OSI/network model and self-automata propagation has anything to do with arbitrary write permissions to a remote network leveraging from the application layer, then me and you have nothing to talk about. As for the exploitability of this vulnerability, you will never know until you try. And we have tried it , and seem to know better. I suggest you read the report again. Thank you. -- Forwarded message -- From: Nicholas Lemonias. lem.niko...@googlemail.com Date: Thu, Mar 13, 2014 at 7:47 PM Subject: Re: [Full-disclosure] Google vulnerabilities with PoC To: Julius Kivimäki julius.kivim...@gmail.com Julius Kivimaki, your disbelief in OWASP, CEH, Journalists and anything you may, or may not be qualified to question amazes. But everyone's opinion is of course respected. I normally don't provide security lessons via e-mail and full-disclosure, however you seem not to understand the security report fully and some core principles. If you can't see what information security best practises, the OSI/network model and self-automata propagation has anything to do with arbitrary write permissions to a remote network leveraging from the application layer, then me and you have nothing to talk about. As for the exploitability of this vulnerability, you will never know until you try. And we have tried it , and seem to know better. I suggest you read the report again. Thank you. On Thu, Mar 13, 2014 at 7:02 PM, Julius Kivimäki julius.kivim...@gmail.comwrote: I don't see what OSI model has to do with anything here. Why is arbitrary file upload to youtube CDN any worse than to google drive CDN? And how will your self-executing encrypted virus like Cryptolocker end up getting executed anyways? And cryptolocker was definitely not self-executing, but spread via email attachments (excluding the boring USB spread functionality). What you have here is not a vulnerability, just give up. And stop trying to get journalists like Eduard Kovacs to spread your BS. 2014-03-13 19:10 GMT+02:00 Nicholas Lemonias. lem.niko...@googlemail.com : Hello Julius, I appreciate your interest to learn more. OWASP is quite credible, and has gained some international recognition. It is a benchmark for many vendors. I suggest you to read on OSI/7-Layer Model. A website may disallow uploads of certain file types for security reasons, and let's assume at the application layer. If we manage to get past the security controls, that means we can write unrestrictedly any type of file to the remote network. That also means that we get past their firewall, since the communication is through HTTP (port 80). CDN nodes are deployed to multiple colocation (thousands of nodes and thousands of servers across the world). The files (let's say a self-executing encrypted virus like Cryptolocker? ) are cached deeply in the network across thousands of servers. On Thu, Mar 13, 2014 at 5:07 PM, Nicholas Lemonias. lem.niko...@googlemail.com wrote: Hello Julius, I appreciate your interest to learn more. OWASP is quite credible, and has gained some international recognition. It is a benchmark for many vendors. I suggest you to read on OSI/7-Layer Model. A website may disallow uploads of certain file types for security reasons, and let's assume at the application layer. If we manage to get past the security controls, that means we can write unrestrictedly any type of file to the remote network. That also means that we get past their firewall, since the communication is through HTTP (port 80). CDN nodes are deployed to multiple colocation (thousands of nodes and thousands of servers across the world). The files are cached deep in the network structures to thousands of servers. On Thu, Mar 13, 2014 at 4:20 PM, Julius Kivimäki julius.kivim...@gmail.com wrote: OWASP is recognized worldwide, so is CEH and a bunch of other morons. That doesn't mean their publications are worth anything. Now tell me, why would arbitrary file upload on a CDN lead to code execution (Besides for HTML, which you have been unable to confirm)? 2014-03-13 18:16 GMT+02:00 Nicholas Lemonias. lem.niko...@googlemail.com: *You are wrong about accessing the files. What has not been confirmed is remote code execution. We are working on it.* *And please, OWASP is recognised worldwide... * *Files can be accessed through Google Take out with a little bit of skills.* *https://www.google.com/settings/takeout https://www.google.com/settings/takeout * On Thu, Mar 13, 2014 at 4:09 PM, Julius Kivimäki julius.kivim...@gmail.com wrote:
Re: [Full-disclosure] Google vulnerabilities with PoC
Hello Zalewski, The YouTube service is there to serve harmless media files. The upload functionality is there to upload files legitimately. But what type of files, and who can write those files? What's the difference between a Youtube admin and a Youtube user in terms of permissions sets ? Why does Youtube accepts only a certain type of media-files? Isn't it because that's the scope of its function ? A good point made, however based on recognised practise and core principles of Information Security and not just 'experience' or personal belief, once the information security flow of a design is tampered - that constitutes to a security issue. Second point - a security vulnerability is present when the confidentiality, integrity and availability of data is affected. In this case the integrity of the service is impacted. On Thu, Mar 13, 2014 at 5:28 PM, Michal Zalewski lcam...@coredump.cxwrote: The only reasonable way to 'exploit' the bug is using youtube as a personal storage uploading non-video files to your own profile: so what? That would require a way to retrieve the stored data, which - as I understand - isn't possible here (although the report seems a bit hard-to-parse). From what I recall, you can just upload a blob of data and essentially see it disappear. We do have quite a few services where you can legitimately upload and share nearly-arbitrary content, though. Google Drive is a good example. /mz ___ 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] WatchGuard Fireware XTM devices contain a cross-site scripting vulnerability (CVE-2014-0338)
I. VULNERABILITY - Reflected XSS Attacks vulnerabilities in WatchGuard XTM 11.8 II. BACKGROUND - WatchGuard builds affordable, all-in-one network and content security solutions to provide defense in depth for corporate content, networks and the businesses they power. III. DESCRIPTION - Has been detected a Reflected XSS vulnerability in XTM WatchGuard. The code injection is done through the parameter poll_name in the page /firewall/policy?pol_name=(HERE XSS) IV. PROOF OF CONCEPT - The application does not validate the parameter poll_name correctly. https://10.200.210.100:8080/firewall/policy?pol_name=qqq;body onload=alert(document.cookie)service=Anyis_new=1 V. BUSINESS IMPACT - An attacker can execute arbitrary HTML or script code in a targeted user's browser, that allows the execution of arbitrary HTML/script code to be executed in the context of the victim user's browser allowing Cookie Theft/Session Hijacking, thus enabling full access the box. VI. SYSTEMS AFFECTED - Tested WatchGuard XTM Version: 11.8 (Build 432340) VII. SOLUTION - All data received by the application and can be modified by the user, before making any kind of transaction with them must be validated VIII. References - http://www.kb.cert.org/vuls/id/807134 http://watchguardsecuritycenter.com/2014/03/13/fireware-xtm-11-8-3-update-corrects-xss-flaw/ By William Costa william.co...@gmail.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] Google vulnerabilities with PoC
The YouTube service is there to serve harmless media files. The upload functionality is there to upload files legitimately. But what type of files, and who can write those files? What's the difference between a Youtube admin (admin.youtube.com) and a Youtube user in terms of permissions sets ? Why does Youtube accepts only a certain type of media-files? Isn't it because that's the scope of its function ? A good point made, however based on recognised practise and core principles of Information Security and not just 'experience' or personal belief, once the information security flow of a design is tampered - that constitutes to a security issue. Second point - a security vulnerability is present when the confidentiality, integrity and availability of data is affected. In this case the integrity of the service is impacted. On Thu, Mar 13, 2014 at 8:00 PM, Nicholas Lemonias. lem.niko...@googlemail.com wrote: Hello Zalewski, The YouTube service is there to serve harmless media files. The upload functionality is there to upload files legitimately. But what type of files, and who can write those files? What's the difference between a Youtube admin and a Youtube user in terms of permissions sets ? Why does Youtube accepts only a certain type of media-files? Isn't it because that's the scope of its function ? A good point made, however based on recognised practise and core principles of Information Security and not just 'experience' or personal belief, once the information security flow of a design is tampered - that constitutes to a security issue. Second point - a security vulnerability is present when the confidentiality, integrity and availability of data is affected. In this case the integrity of the service is impacted. On Thu, Mar 13, 2014 at 5:28 PM, Michal Zalewski lcam...@coredump.cxwrote: The only reasonable way to 'exploit' the bug is using youtube as a personal storage uploading non-video files to your own profile: so what? That would require a way to retrieve the stored data, which - as I understand - isn't possible here (although the report seems a bit hard-to-parse). From what I recall, you can just upload a blob of data and essentially see it disappear. We do have quite a few services where you can legitimately upload and share nearly-arbitrary content, though. Google Drive is a good example. /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Google vulnerabilities with PoC
We confirm this to be a valid vulnerability for the following reasons. The access control subsystem is defeated, resulting to arbitrary write access of any file of choice. 1. You Tube defines which file types are permitted to be uploaded. 2. Exploitation is achieved by circumvention of web-based security controls (namely http forms, which is a weak security measure). However, exploitation of the issue results to unrestricted file uploads (any file of choice ). Remote code execution may be possible either through social engineering , or by stochastically rewriting an existing file-structure in the CDN. 3. This directly impacts the integrity of the service since modification of information occurs by circumvention. Renaming the uploaded files can be achieved through YouTube's inherent video manager. 4. Denial of Service attacks are feasible since we bypass all security restrictions. This directly impacts the availability of the service. 5. Malware propagation is possible, if the planted code get's executed through social engineering or by re-writing a valid file system structure. 6) All uploaded files can be downloaded through Google Take Out, if past the Content ID filtering algorithm (through file header obfuscation and encryption). Best Regards, Nicholas Lemonias Advanced Information Security Corp. ___ 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 2879-1] libssh security update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - - Debian Security Advisory DSA-2879-1 secur...@debian.org http://www.debian.org/security/ Raphael Geissert March 13, 2014 http://www.debian.org/security/faq - - Package: libssh CVE ID : CVE-2014-0017 It was discovered that libssh, a tiny C SSH library, did not reset the state of the PRNG after accepting a connection. A server mode application that forks itself to handle incoming connections could see its children sharing the same PRNG state, resulting in a cryptographic weakness and possibly the recovery of the private key. For the oldstable distribution (squeeze), this problem has been fixed in version 0.4.5-3+squeeze2. For the stable distribution (wheezy), this problem has been fixed in version 0.5.4-1+deb7u1. For the testing distribution (jessie), this problem has been fixed in version 0.5.4-3. For the unstable distribution (sid), this problem has been fixed in version 0.5.4-3. We recommend that you upgrade your libssh packages. Further information about Debian Security Advisories, how to apply these updates to your system and frequently asked questions can be found at: http://www.debian.org/security/ Mailing list: debian-security-annou...@lists.debian.org -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlMiKRUACgkQYy49rUbZzlqkuwCcD1w6TIHTZ/zRqpgKgaMBGVNh KbQAn1rRP1QFKemOY/cj5MUMDQtJnuPX =92PH -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] Google vulnerabilities with PoC
On 2014-03-14 10:56, andfarm wrote: On Mar 13, 2014, at 10:33, Brandon Perry bperry.volat...@gmail.com wrote: If you were evil, you could upload huge blobs and just take up space on the google servers. Who knows what will happen if you upload a couple hundred gigs of files. They dont disappear, they are just unretrievable afaict. It is a security risk in the sense that untrusted data is being persisted *somewhere*. It's not even clear at this point that the uploaded data is even being persisted! Since the uploaded file is not made available for download, it's entirely possible that it is being deleted as soon as Google's video transcoding systems discover it isn't a supported video format. In the email reply from google they confirmed that it was stored, but you can't get it out so kind of a moot point :D The comments on the Softpedia article are painfully stupid, by the way. I recommend not reading them. :) ___ 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] Fwd: Hacking Exposed: Virtualization Cloud Computing: Secrets Solutions
Anyone know? -- Forwarded message -- From: Kristian Erik Hermansen kristian.herman...@gmail.com Date: Thu, Mar 13, 2014 at 1:13 PM Subject: Hacking Exposed: Virtualization Cloud Computing: Secrets Solutions To: dailydave dailyd...@lists.immunityinc.com, dailyd...@lists.immunitysec.com Does anyone know if this book exists or has ever been released? Seems mythically unicorn-like and The Hoff didn't seem to have an answer either :) 1 Used from $742.67??? http://www.amazon.com/gp/product/B00BZTW7E2/ ... -- Regards, Kristian Erik Hermansen https://www.linkedin.com/in/kristianhermansen https://google.com/+KristianHermansen ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Google vulnerabilities with PoC
Nicholas, I remember my early years in the infosec community - and sadly, so do some of the more seasoned readers of this list :-) Back then, I thought that the only thing that mattered is the ability to find bugs. But after some 18 years in the industry, I now know that there's an even more important and elusive skill. That skill boils down to having a robust mental model of what constitutes a security flaw - and being able to explain your thinking to others in a precise and internally consistent manner that convinces others to act. We need this because the security of a system can't be usefully described using abstract terms: even the academic definitions ultimately boil down to saying the system is secure if it doesn't do the things we *really* don't want it to do. In this spirit, the term vulnerability is generally reserved for behaviors that meet all of the following criteria: 1) The behavior must have negative consequences for at least one of the legitimate stakeholders (users, service owners, etc), 2) The consequences must be widely seen as unexpected and unacceptable, 3) There must be a realistic chance of such a negative outcome, 4) The behavior must introduce substantial new risks that go beyond the previously accepted trade-offs. If we don't have that, we usually don't have a case, no matter how clever the bug is. Cheers (and happy hunting!), /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
