Re: [Full-disclosure] VUPEN Security Research - Adobe Flash Player RTMP Data Processing Object Confusion (CVE-2013-2555)
Oh, no, please not again. Are we going to talk one more fucking time about the ethics of 0-days? Please no. Is a delay of a year before reporting to the vendor, acceptable? Thanks, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of Sydney Australia 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/
Re: [Full-disclosure] VUPEN Security Research - Adobe Flash Player RTMP Data Processing Object Confusion (CVE-2013-2555)
I was suddenly reminded of this... http://www.quickmeme.com/meme/3qicaz/ On Sat, Apr 20, 2013 at 1:05 PM, Joxean Koret joxeanko...@yahoo.es wrote: Oh, no, please not again. Are we going to talk one more fucking time about the ethics of 0-days? Please no. Is a delay of a year before reporting to the vendor, acceptable? Thanks, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of Sydney Australia ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ -- “There's a reason we separate military and the police: one fights the enemy of the state, the other serves and protects the people. When the military becomes both, then the enemies of the state tend to become the people.” ___ 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] [ MDVSA-2013:147 ] libarchive
valdis.kletni...@vt.edu wrote: On Fri, 19 Apr 2013 12:30:12 -0400, l3thal said: looks like you are still at it heh... procmail is your friend. would work even better if people didn't make copies of the entire mail and adding their little complaint. ___ 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] [ MDVSA-2013:147 ] libarchive
I really wonder if they even read the lists they spam 2013/4/19 l3thal l3t...@smashthestack.org looks like you are still at it heh... On Fri, Apr 19, 2013 at 11:12 AM, secur...@mandriva.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ___ Mandriva Linux Security Advisory MDVSA-2013:147 http://www.mandriva.com/en/support/security/ ___ Package : libarchive Date: April 19, 2013 Affected: Business Server 1.0, Enterprise Server 5.0 ___ Problem Description: A vulnerability has been found and corrected in libarchive: Fabian Yamaguchi reported a read buffer overflow flaw in libarchive on 64-bit systems where sizeof(size_t) is equal to 8. In the archive_write_zip_data() function in libarchive/ archive_write_set_format_zip.c, the quot;squot; parameter is of type size_t (64 bit, unsigned) and is cast to a 64 bit signed integer. If quot;squot; is larger than MAX_INT, it will not be set to quot;zip-gt;remaining_data_bytesquot; even though it is larger than quot;zip-gt;remaining_data_bytesquot;, which leads to a buffer overflow when calling deflate(). This can lead to a segfault in an application that uses libarchive to create ZIP archives (CVE-2013-0211). The updated packages have been patched to correct this issue. ___ References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-0211 https://wiki.mageia.org/en/Support/Advisories/MGASA-2013-0119 ___ Updated Packages: Mandriva Enterprise Server 5: db7909eb958a090af3abeec3e4427f20 mes5/i586/bsdtar-2.5.5-1.2mdvmes5.2.i586.rpm 8ce2a7ce2501bb7bd6a53e3dffd8fd31 mes5/i586/libarchive2-2.5.5-1.2mdvmes5.2.i586.rpm ba4c4e8717271abf9f2228886617409c mes5/i586/libarchive-devel-2.5.5-1.2mdvmes5.2.i586.rpm 52d76a6e66d3e63c981b947dc8d58f50 mes5/SRPMS/libarchive-2.5.5-1.2mdvmes5.2.src.rpm Mandriva Enterprise Server 5/X86_64: f922a9da676ae2d2de2f717bd5841c73 mes5/x86_64/bsdtar-2.5.5-1.2mdvmes5.2.x86_64.rpm 4218a2812e89dc233b1e1eeb6f407e44 mes5/x86_64/lib64archive2-2.5.5-1.2mdvmes5.2.x86_64.rpm a928fa095d7cf3f3ef5c4338b1fba506 mes5/x86_64/lib64archive-devel-2.5.5-1.2mdvmes5.2.x86_64.rpm 52d76a6e66d3e63c981b947dc8d58f50 mes5/SRPMS/libarchive-2.5.5-1.2mdvmes5.2.src.rpm Mandriva Business Server 1/X86_64: 05b377385a447c33cd6e85efeeaa4fd0 mbs1/x86_64/bsdcpio-3.0.3-2.1.mbs1.x86_64.rpm 3ff28cd1ce2047a8dfed99a978d238a2 mbs1/x86_64/bsdtar-3.0.3-2.1.mbs1.x86_64.rpm 4adb27059351ae756462e9e25c87e11e mbs1/x86_64/lib64archive12-3.0.3-2.1.mbs1.x86_64.rpm 52850e175df3b0b48a307d87c7b5f3ea mbs1/x86_64/lib64archive-devel-3.0.3-2.1.mbs1.x86_64.rpm 890acf6fa9dafa2303be49bc1d42bdf1 mbs1/SRPMS/libarchive-3.0.3-2.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) iD8DBQFRcTdymqjQ0CJFipgRAs/4AKC3K7COuqRwVL6Ecq8yZ8chXthyWQCg04Q5 PRlg9lwbUt4q80+7fmRJ8Kk= =jL85 -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/ -- l3thal - SmashTheStack http://smashthestack.org ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ ___ 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] VUPEN Security Research - Adobe Flash Player RTMP Data Processing Object Confusion (CVE-2013-2555)
Yeah it is when you are in the business of selling exploits. 2013/4/19 paul.sz...@sydney.edu.au VUPEN Security Research advisor...@vupen.com wrote in http://www.securityfocus.com/archive/1/526402 : X. DISCLOSURE TIMELINE 2012-02-15 - Vulnerability Discovered by VUPEN 2013-03-06 - Vulnerability Exploited At Pwn2Own 2013 and Reported to Adobe 2013-04-17 - Public disclosure Is a delay of a year before reporting to the vendor, acceptable? Thanks, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ ___ 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] VUPEN Security Research - Adobe Flash Player RTMP Data Processing Object Confusion (CVE-2013-2555)
Why instead of discussing about ethics about 0days, don't you discuss about responsible DEVELOPMENT instead? If products where properly designed and developed there wouldn't be 0days for them, would them? - sergio On Apr 20, 2013 2:17 PM, Mario Vilas mvi...@gmail.com wrote: I was suddenly reminded of this... http://www.quickmeme.com/meme/3qicaz/ On Sat, Apr 20, 2013 at 1:05 PM, Joxean Koret joxeanko...@yahoo.es wrote: Oh, no, please not again. Are we going to talk one more fucking time about the ethics of 0-days? Please no. Is a delay of a year before reporting to the vendor, acceptable? Thanks, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of Sydney Australia ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ -- “There's a reason we separate military and the police: one fights the enemy of the state, the other serves and protects the people. When the military becomes both, then the enemies of the state tend to become the people.” ___ 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] VUPEN Security Research - Adobe Flash Player RTMP Data Processing Object Confusion (CVE-2013-2555)
On 4/20/13, Sergio Alvarez shad...@gmail.com wrote: Why instead of discussing about ethics about 0days, don't you discuss about responsible DEVELOPMENT instead? If products where properly designed and developed there wouldn't be 0days for them, would them? Only if the designers developers were perfect and never made mistakes. - sergio On Apr 20, 2013 2:17 PM, Mario Vilas mvi...@gmail.com wrote: I was suddenly reminded of this... http://www.quickmeme.com/meme/3qicaz/ On Sat, Apr 20, 2013 at 1:05 PM, Joxean Koret joxeanko...@yahoo.es wrote: Oh, no, please not again. Are we going to talk one more fucking time about the ethics of 0-days? Please no. Is a delay of a year before reporting to the vendor, acceptable? Thanks, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of Sydney Australia ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ -- “There's a reason we separate military and the police: one fights the enemy of the state, the other serves and protects the people. When the military becomes both, then the enemies of the state tend to become the people.” ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] [SECURITY] [DSA 2660-1] curl security update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - - Debian Security Advisory DSA-2660-1 secur...@debian.org http://www.debian.org/security/ Salvatore Bonaccorso April 20, 2013 http://www.debian.org/security/faq - - Package: curl Vulnerability : exposure of sensitive information Problem type : remote Debian-specific: no CVE ID : CVE-2013-1944 Debian Bug : 705274 Yamada Yasuharu discovered that cURL, an URL transfer library, is vulnerable to expose potentially sensitive information when doing requests across domains with matching tails. Due to a bug in the tailmatch function when matching domain names, it was possible that cookies set for a domain 'ample.com' could accidentally also be sent by libcurl when communicating with 'example.com'. Both curl the command line tool and applications using the libcurl library are vulnerable. For the stable distribution (squeeze), this problem has been fixed in version 7.21.0-2.1+squeeze3. For the testing distribution (wheezy), this problem has been fixed in version 7.26.0-1+wheezy2. For the unstable distribution (sid), this problem has been fixed in version 7.29.0-2.1. We recommend that you upgrade your curl 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.4.12 (GNU/Linux) iQEcBAEBAgAGBQJRcqt6AAoJEFb2GnlAHawEJsgH/RFAPpyxjMJs5IUbnaGBB17w p3sfg7uC92mYHvUcXb2tXLzJTJ7QBWZTbvo9Dnr0r72WU9AJCmOZ3FiSrU6hlLZG QommSJgi+614IjQV6IcYIs5MM4Ne/KNBAcz31ROr5xqRNLQo4N6cxBj9NKnsi1Ut f6xrQInVKp5WNx3qMGtxAKfVrCMcMRM0OTW+ASJI1r4smVSVdUBrJSkk0mg08jZG QQeAXtOOSbkahKpwcgGETgU+l1MTYkgjSZwwRtWJUbdPSeUrNl8SHM9Fa7h1c/j9 b/2odiynlhXYyOkj1PyPaNireEBsLOCY2xRZH27fZGh6AXFC07KS6Io4NYnDfJQ= =MBDd -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] Multiple vulnerabilities in Colormix theme for WordPress
Hello list! Last year I've disclosed vulnerabilities in JW Player and in RokBox. Which were fixed by the developers - JW Player developers fixed one hole and promised to fix others later and RokBox fixed all holes (but it was questionable how they fixed holes related to JW Player). In December I've wrote about 47 RocketTheme's themes for WordPress (which contain RokBox). Besides their themes I've found in December similar vulnerabilities in multiple themes of other developers (including custom themes). Now I'll inform you about multiple vulnerabilities in Colormix theme for WordPress. These are Cross-Site Scripting, Content Spoofing and Full path disclosure vulnerabilities. - Affected products: - Affected all versions of Colormix theme for WordPress. Other themes of this developer can be vulnerable as well. - Affected vendors: - Wordpress Themes Park http://www.wordpressthemespark.com -- Details: -- XSS (WASC-08): http://site/wp-content/themes/colormix/js/rokbox/jwplayer/jwplayer.swf?abouttext=Playeraboutlink=data:text/html;base64,PHNjcmlwdD5hbGVydChkb2N1bWVudC5jb29raWUpPC9zY3JpcHQ%2B Content Spoofing (WASC-12): In parameter file there can be set as video, as audio files. Swf-file of JW Player accepts arbitrary addresses in parameters file and image, which allows to spoof content of flash - i.e. by setting addresses of video (audio) and/or image files from other site. http://site/wp-content/themes/colormix/js/rokbox/jwplayer/jwplayer.swf?file=1.flvbackcolor=0xFFscreencolor=0xFF http://site/wp-content/themes/colormix/js/rokbox/jwplayer/jwplayer.swf?file=1.flvimage=1.jpg Content Spoofing (WASC-12): Swf-file of JW Player accepts arbitrary addresses in parameter config, which allows to spoof content of flash - i.e. by setting address of config file from other site (parameters file and image in xml-file accept arbitrary addresses). For loading of config file from other site it needs to have crossdomain.xml. http://site/wp-content/themes/colormix/js/rokbox/jwplayer/jwplayer.swf?config=1.xml 1.xml config file1.flv/file image1.jpg/image /config Content Spoofing (WASC-12): http://site/wp-content/themes/colormix/js/rokbox/jwplayer/jwplayer.swf?abouttext=Playeraboutlink=http://site Full path disclosure (WASC-13): There are FPD In folder http://site/wp-content/themes/colormix/ in index.php and many other php-files of theme. Timeline: 2012.05.29 - informed developers of JW Player. 2012.08.18 - informed developers about new holes in JW Player Pro. 2012.08.28 - informed developers of Rokbox. 2012.12.14 - disclosed at my site about Rokbox. 2012.12.23 - disclosed to the lists the first part of vulnerable themes by RocketTheme for WordPress. 2012.12.30 - disclosed to the lists the second part of vulnerable themes by RocketTheme for WordPress. 2013.04.18 - disclosed at my site about Colormix theme (http://websecurity.com.ua/6457/). Best wishes regards, MustLive Administrator of Websecurity web site http://websecurity.com.ua ___ 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] VUPEN Security Research - Adobe Flash Player RTMP Data Processing Object Confusion (CVE-2013-2555)
The code monkeys can make mistakes as long as there is a process to detect and remedy their mistakes before things get shipped. Hiring decent application security researchers to audit their code would be a good start. On Sat, Apr 20, 2013 at 09:51:40AM -0400, Lee wrote: On 4/20/13, Sergio Alvarez shad...@gmail.com wrote: Why instead of discussing about ethics about 0days, don't you discuss about responsible DEVELOPMENT instead? If products where properly designed and developed there wouldn't be 0days for them, would them? Only if the designers developers were perfect and never made mistakes. ___ 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] VUPEN Security Research - Adobe Flash Player RTMP Data Processing Object Confusion (CVE-2013-2555)
Yes, after the people that can make mistakes, we should have people that are incapable of making mistakes. I totally agree, what a good idea. On Sat, Apr 20, 2013 at 10:28 PM, Bryan br...@unhwildhats.com wrote: The code monkeys can make mistakes as long as there is a process to detect and remedy their mistakes before things get shipped. Hiring decent application security researchers to audit their code would be a good start. On Sat, Apr 20, 2013 at 09:51:40AM -0400, Lee wrote: On 4/20/13, Sergio Alvarez shad...@gmail.com wrote: Why instead of discussing about ethics about 0days, don't you discuss about responsible DEVELOPMENT instead? If products where properly designed and developed there wouldn't be 0days for them, would them? Only if the designers developers were perfect and never made mistakes. ___ 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] VUPEN Security Research - Adobe Flash Player RTMP Data Processing Object Confusion (CVE-2013-2555)
Let me expand on that, otherwise I'm sure it's unclear. Is your suggestion, to remove the worry of developers making mistakes, to add another human process after it and rely on this to remove all mistakes? On Sat, Apr 20, 2013 at 10:54 PM, Benji m...@b3nji.com wrote: Yes, after the people that can make mistakes, we should have people that are incapable of making mistakes. I totally agree, what a good idea. On Sat, Apr 20, 2013 at 10:28 PM, Bryan br...@unhwildhats.com wrote: The code monkeys can make mistakes as long as there is a process to detect and remedy their mistakes before things get shipped. Hiring decent application security researchers to audit their code would be a good start. On Sat, Apr 20, 2013 at 09:51:40AM -0400, Lee wrote: On 4/20/13, Sergio Alvarez shad...@gmail.com wrote: Why instead of discussing about ethics about 0days, don't you discuss about responsible DEVELOPMENT instead? If products where properly designed and developed there wouldn't be 0days for them, would them? Only if the designers developers were perfect and never made mistakes. ___ 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] VUPEN Security Research - Adobe Flash Player RTMP Data Processing Object Confusion (CVE-2013-2555)
I am just saying that developers and designers make mistakes and that there is no getting around that. Rather than relying on the benevolent 0day researchers from the sky publicly disclosing their vulnerabilities, more responsible QA testing within the company will prevent many of these vulnerabilities from occurring in the first place. Or do you have a better idea? On Sat, Apr 20, 2013 at 11:06:33PM +0100, Benji wrote: Let me expand on that, otherwise I'm sure it's unclear. Is your suggestion, to remove the worry of developers making mistakes, to add another human process after it and rely on this to remove all mistakes? On Sat, Apr 20, 2013 at 10:54 PM, Benji m...@b3nji.com wrote: Yes, after the people that can make mistakes, we should have people that are incapable of making mistakes. I totally agree, what a good idea. On Sat, Apr 20, 2013 at 10:28 PM, Bryan br...@unhwildhats.com wrote: The code monkeys can make mistakes as long as there is a process to detect and remedy their mistakes before things get shipped. Hiring decent application security researchers to audit their code would be a good start. On Sat, Apr 20, 2013 at 09:51:40AM -0400, Lee wrote: On 4/20/13, Sergio Alvarez shad...@gmail.com wrote: Why instead of discussing about ethics about 0days, don't you discuss about responsible DEVELOPMENT instead? If products where properly designed and developed there wouldn't be 0days for them, would them? Only if the designers developers were perfect and never made mistakes. ___ 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] VUPEN Security Research - Adobe Flash Player RTMP Data Processing Object Confusion (CVE-2013-2555)
Yes, a better idea would be to educate and inform developers. At a business level atleast this will a) save extra expenditure on needless staff and extra departments b) result in faster turn arounds as there's then less time needed for remediation. At a technical level, it will atleast result in less 'dumb' bugs (assuming training and education is effective and relevant). I think at this point expecting software to have 0 flaws or being under the illusion that software will ever be flawless in it's current state is like wishing really hard before bed every night that genetics and evolution will make you a unicorn. On Sat, Apr 20, 2013 at 11:35 PM, Bryan br...@unhwildhats.com wrote: I am just saying that developers and designers make mistakes and that there is no getting around that. Rather than relying on the benevolent 0day researchers from the sky publicly disclosing their vulnerabilities, more responsible QA testing within the company will prevent many of these vulnerabilities from occurring in the first place. Or do you have a better idea? On Sat, Apr 20, 2013 at 11:06:33PM +0100, Benji wrote: Let me expand on that, otherwise I'm sure it's unclear. Is your suggestion, to remove the worry of developers making mistakes, to add another human process after it and rely on this to remove all mistakes? On Sat, Apr 20, 2013 at 10:54 PM, Benji m...@b3nji.com wrote: Yes, after the people that can make mistakes, we should have people that are incapable of making mistakes. I totally agree, what a good idea. On Sat, Apr 20, 2013 at 10:28 PM, Bryan br...@unhwildhats.com wrote: The code monkeys can make mistakes as long as there is a process to detect and remedy their mistakes before things get shipped. Hiring decent application security researchers to audit their code would be a good start. On Sat, Apr 20, 2013 at 09:51:40AM -0400, Lee wrote: On 4/20/13, Sergio Alvarez shad...@gmail.com wrote: Why instead of discussing about ethics about 0days, don't you discuss about responsible DEVELOPMENT instead? If products where properly designed and developed there wouldn't be 0days for them, would them? Only if the designers developers were perfect and never made mistakes. ___ 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] VUPEN Security Research - Adobe Flash Player RTMP Data Processing Object Confusion (CVE-2013-2555)
(in my opinion) On Sat, Apr 20, 2013 at 11:42 PM, Benji m...@b3nji.com wrote: Yes, a better idea would be to educate and inform developers. At a business level atleast this will a) save extra expenditure on needless staff and extra departments b) result in faster turn arounds as there's then less time needed for remediation. At a technical level, it will atleast result in less 'dumb' bugs (assuming training and education is effective and relevant). I think at this point expecting software to have 0 flaws or being under the illusion that software will ever be flawless in it's current state is like wishing really hard before bed every night that genetics and evolution will make you a unicorn. On Sat, Apr 20, 2013 at 11:35 PM, Bryan br...@unhwildhats.com wrote: I am just saying that developers and designers make mistakes and that there is no getting around that. Rather than relying on the benevolent 0day researchers from the sky publicly disclosing their vulnerabilities, more responsible QA testing within the company will prevent many of these vulnerabilities from occurring in the first place. Or do you have a better idea? On Sat, Apr 20, 2013 at 11:06:33PM +0100, Benji wrote: Let me expand on that, otherwise I'm sure it's unclear. Is your suggestion, to remove the worry of developers making mistakes, to add another human process after it and rely on this to remove all mistakes? On Sat, Apr 20, 2013 at 10:54 PM, Benji m...@b3nji.com wrote: Yes, after the people that can make mistakes, we should have people that are incapable of making mistakes. I totally agree, what a good idea. On Sat, Apr 20, 2013 at 10:28 PM, Bryan br...@unhwildhats.com wrote: The code monkeys can make mistakes as long as there is a process to detect and remedy their mistakes before things get shipped. Hiring decent application security researchers to audit their code would be a good start. On Sat, Apr 20, 2013 at 09:51:40AM -0400, Lee wrote: On 4/20/13, Sergio Alvarez shad...@gmail.com wrote: Why instead of discussing about ethics about 0days, don't you discuss about responsible DEVELOPMENT instead? If products where properly designed and developed there wouldn't be 0days for them, would them? Only if the designers developers were perfect and never made mistakes. ___ 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] VUPEN Security Research - Adobe Flash Player RTMP Data Processing Object Confusion (CVE-2013-2555)
I think the definition of 'needless staff' highly depends on whether you want 'vulnerable software'. Educating current developers is absolutely a good idea, but still not foolproof. The bottom line is that if you want safe software, you need to invest in proper development. As far as I am concerned, for large companies like Adobe and Oracle, where software bugs in your product have a direct impact on the safety of your customers, that involves hiring specialized staff. On Sat, Apr 20, 2013 at 11:49:22PM +0100, Benji wrote: (in my opinion) On Sat, Apr 20, 2013 at 11:42 PM, Benji m...@b3nji.com wrote: Yes, a better idea would be to educate and inform developers. At a business level atleast this will a) save extra expenditure on needless staff and extra departments b) result in faster turn arounds as there's then less time needed for remediation. At a technical level, it will atleast result in less 'dumb' bugs (assuming training and education is effective and relevant). I think at this point expecting software to have 0 flaws or being under the illusion that software will ever be flawless in it's current state is like wishing really hard before bed every night that genetics and evolution will make you a unicorn. On Sat, Apr 20, 2013 at 11:35 PM, Bryan br...@unhwildhats.com wrote: I am just saying that developers and designers make mistakes and that there is no getting around that. Rather than relying on the benevolent 0day researchers from the sky publicly disclosing their vulnerabilities, more responsible QA testing within the company will prevent many of these vulnerabilities from occurring in the first place. Or do you have a better idea? ___ 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] VUPEN Security Research - Adobe Flash Player RTMP Data Processing Object Confusion (CVE-2013-2555)
Your proposition was that developers will always make mistakes and introduce stupid problems, so a QA team/process is necessary. While I agree that there should be a QA/'audit' at some point, it shouldnt be the stage that is relied on. Applications that are flawed from the design stage onwards will become expenditure blackholes, especially after going through any QA process which should highlight these. Potentially yes, but most of the larger companies appear to already do this. A quick search through google shows that Oracle atleast already have, and/or are actively hiring security engineers involved with Java (for example). Flaws will always pop up and I think we may now be bordering on discussing what counts as negligence in some cases. Your 5-chained-0day-to-code-exec, in my opinion, does not count as negligence and comes from the developer effectively not being a security engineer, but doing the job of a developer. In my opinion we are not at the stage in industry where we can consider/expect any developer to think through each implication of each feature they implement, without a strong security background as much as we may appreciate it. Negligence in my opinion of security vulnerabilities is having obvious format string bugs/buffer overflows when handling user input for example, or incorrect permissions, or just a lack of consideration to obvious problems. Developer training should pick up on the obvious bugs, or atleast give developers an understanding of how to handle users/user input in a safe manner, and know the implications of not doing so. On Sat, Apr 20, 2013 at 11:58 PM, Bryan br...@unhwildhats.com wrote: I think the definition of 'needless staff' highly depends on whether you want 'vulnerable software'. Educating current developers is absolutely a good idea, but still not foolproof. The bottom line is that if you want safe software, you need to invest in proper development. As far as I am concerned, for large companies like Adobe and Oracle, where software bugs in your product have a direct impact on the safety of your customers, that involves hiring specialized staff. On Sat, Apr 20, 2013 at 11:49:22PM +0100, Benji wrote: (in my opinion) On Sat, Apr 20, 2013 at 11:42 PM, Benji m...@b3nji.com wrote: Yes, a better idea would be to educate and inform developers. At a business level atleast this will a) save extra expenditure on needless staff and extra departments b) result in faster turn arounds as there's then less time needed for remediation. At a technical level, it will atleast result in less 'dumb' bugs (assuming training and education is effective and relevant). I think at this point expecting software to have 0 flaws or being under the illusion that software will ever be flawless in it's current state is like wishing really hard before bed every night that genetics and evolution will make you a unicorn. On Sat, Apr 20, 2013 at 11:35 PM, Bryan br...@unhwildhats.com wrote: I am just saying that developers and designers make mistakes and that there is no getting around that. Rather than relying on the benevolent 0day researchers from the sky publicly disclosing their vulnerabilities, more responsible QA testing within the company will prevent many of these vulnerabilities from occurring in the first place. Or do you have a better idea? ___ 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] VUPEN Security Research - Adobe Flash Player RTMP Data Processing Object Confusion (CVE-2013-2555)
Your 5-chained-0day-to-code-exec, in my opinion, does not count as negligence and comes from the developer effectively not being a security engineer Solution: Hire security engineers. In my opinion we are not at the stage in industry where we can consider/expect any developer to think through each implication of each feature they implement Solution: Hire security engineers to think through each implication. Why are we disagreeing? On Sun, Apr 21, 2013 at 12:11:51AM +0100, Benji wrote: Your proposition was that developers will always make mistakes and introduce stupid problems, so a QA team/process is necessary. While I agree that there should be a QA/'audit' at some point, it shouldnt be the stage that is relied on. Applications that are flawed from the design stage onwards will become expenditure blackholes, especially after going through any QA process which should highlight these. Potentially yes, but most of the larger companies appear to already do this. A quick search through google shows that Oracle atleast already have, and/or are actively hiring security engineers involved with Java (for example). Flaws will always pop up and I think we may now be bordering on discussing what counts as negligence in some cases. Your 5-chained-0day-to-code-exec, in my opinion, does not count as negligence and comes from the developer effectively not being a security engineer, but doing the job of a developer. In my opinion we are not at the stage in industry where we can consider/expect any developer to think through each implication of each feature they implement, without a strong security background as much as we may appreciate it. Negligence in my opinion of security vulnerabilities is having obvious format string bugs/buffer overflows when handling user input for example, or incorrect permissions, or just a lack of consideration to obvious problems. Developer training should pick up on the obvious bugs, or atleast give developers an understanding of how to handle users/user input in a safe manner, and know the implications of not doing so. On Sat, Apr 20, 2013 at 11:58 PM, Bryan br...@unhwildhats.com wrote: I think the definition of 'needless staff' highly depends on whether you want 'vulnerable software'. Educating current developers is absolutely a good idea, but still not foolproof. The bottom line is that if you want safe software, you need to invest in proper development. As far as I am concerned, for large companies like Adobe and Oracle, where software bugs in your product have a direct impact on the safety of your customers, that involves hiring specialized staff. ___ 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] VUPEN Security Research - Adobe Flash Player RTMP Data Processing Object Confusion (CVE-2013-2555)
Because security engineers are different to a QA department you originally suggested, and you seem to be very ideologist about the scenarios. As we've seen, Oracle's Java product has security engineers and this has not prevented flaws. On Sun, Apr 21, 2013 at 12:34 AM, Bryan br...@unhwildhats.com wrote: Your 5-chained-0day-to-code-exec, in my opinion, does not count as negligence and comes from the developer effectively not being a security engineer Solution: Hire security engineers. In my opinion we are not at the stage in industry where we can consider/expect any developer to think through each implication of each feature they implement Solution: Hire security engineers to think through each implication. Why are we disagreeing? On Sun, Apr 21, 2013 at 12:11:51AM +0100, Benji wrote: Your proposition was that developers will always make mistakes and introduce stupid problems, so a QA team/process is necessary. While I agree that there should be a QA/'audit' at some point, it shouldnt be the stage that is relied on. Applications that are flawed from the design stage onwards will become expenditure blackholes, especially after going through any QA process which should highlight these. Potentially yes, but most of the larger companies appear to already do this. A quick search through google shows that Oracle atleast already have, and/or are actively hiring security engineers involved with Java (for example). Flaws will always pop up and I think we may now be bordering on discussing what counts as negligence in some cases. Your 5-chained-0day-to-code-exec, in my opinion, does not count as negligence and comes from the developer effectively not being a security engineer, but doing the job of a developer. In my opinion we are not at the stage in industry where we can consider/expect any developer to think through each implication of each feature they implement, without a strong security background as much as we may appreciate it. Negligence in my opinion of security vulnerabilities is having obvious format string bugs/buffer overflows when handling user input for example, or incorrect permissions, or just a lack of consideration to obvious problems. Developer training should pick up on the obvious bugs, or atleast give developers an understanding of how to handle users/user input in a safe manner, and know the implications of not doing so. On Sat, Apr 20, 2013 at 11:58 PM, Bryan br...@unhwildhats.com wrote: I think the definition of 'needless staff' highly depends on whether you want 'vulnerable software'. Educating current developers is absolutely a good idea, but still not foolproof. The bottom line is that if you want safe software, you need to invest in proper development. As far as I am concerned, for large companies like Adobe and Oracle, where software bugs in your product have a direct impact on the safety of your customers, that involves hiring specialized staff. ___ 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] VUPEN Security Research - Adobe Flash Player RTMP Data Processing Object Confusion (CVE-2013-2555)
(For example, http://webcache.googleusercontent.com/search?q=cache:2cXGaaHnqyMJ:www.computerworld.com/s/article/9235954/Researchers_find_critical_vulnerabilities_in_Java_7_Update_11+cd=8hl=enct=clnkgl=uk) On Sun, Apr 21, 2013 at 12:37 AM, Benji m...@b3nji.com wrote: Because security engineers are different to a QA department you originally suggested, and you seem to be very ideologist about the scenarios. As we've seen, Oracle's Java product has security engineers and this has not prevented flaws. On Sun, Apr 21, 2013 at 12:34 AM, Bryan br...@unhwildhats.com wrote: Your 5-chained-0day-to-code-exec, in my opinion, does not count as negligence and comes from the developer effectively not being a security engineer Solution: Hire security engineers. In my opinion we are not at the stage in industry where we can consider/expect any developer to think through each implication of each feature they implement Solution: Hire security engineers to think through each implication. Why are we disagreeing? On Sun, Apr 21, 2013 at 12:11:51AM +0100, Benji wrote: Your proposition was that developers will always make mistakes and introduce stupid problems, so a QA team/process is necessary. While I agree that there should be a QA/'audit' at some point, it shouldnt be the stage that is relied on. Applications that are flawed from the design stage onwards will become expenditure blackholes, especially after going through any QA process which should highlight these. Potentially yes, but most of the larger companies appear to already do this. A quick search through google shows that Oracle atleast already have, and/or are actively hiring security engineers involved with Java (for example). Flaws will always pop up and I think we may now be bordering on discussing what counts as negligence in some cases. Your 5-chained-0day-to-code-exec, in my opinion, does not count as negligence and comes from the developer effectively not being a security engineer, but doing the job of a developer. In my opinion we are not at the stage in industry where we can consider/expect any developer to think through each implication of each feature they implement, without a strong security background as much as we may appreciate it. Negligence in my opinion of security vulnerabilities is having obvious format string bugs/buffer overflows when handling user input for example, or incorrect permissions, or just a lack of consideration to obvious problems. Developer training should pick up on the obvious bugs, or atleast give developers an understanding of how to handle users/user input in a safe manner, and know the implications of not doing so. On Sat, Apr 20, 2013 at 11:58 PM, Bryan br...@unhwildhats.com wrote: I think the definition of 'needless staff' highly depends on whether you want 'vulnerable software'. Educating current developers is absolutely a good idea, but still not foolproof. The bottom line is that if you want safe software, you need to invest in proper development. As far as I am concerned, for large companies like Adobe and Oracle, where software bugs in your product have a direct impact on the safety of your customers, that involves hiring specialized staff. ___ 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] VUPEN Security Research - Adobe Flash Player RTMP Data Processing Object Confusion (CVE-2013-2555)
Sorry, by flaws, I should have said, *has not prevent bad code/ineffective patches from being pushed out On Sun, Apr 21, 2013 at 12:41 AM, Benji m...@b3nji.com wrote: (For example, http://webcache.googleusercontent.com/search?q=cache:2cXGaaHnqyMJ:www.computerworld.com/s/article/9235954/Researchers_find_critical_vulnerabilities_in_Java_7_Update_11+cd=8hl=enct=clnkgl=uk) On Sun, Apr 21, 2013 at 12:37 AM, Benji m...@b3nji.com wrote: Because security engineers are different to a QA department you originally suggested, and you seem to be very ideologist about the scenarios. As we've seen, Oracle's Java product has security engineers and this has not prevented flaws. On Sun, Apr 21, 2013 at 12:34 AM, Bryan br...@unhwildhats.com wrote: Your 5-chained-0day-to-code-exec, in my opinion, does not count as negligence and comes from the developer effectively not being a security engineer Solution: Hire security engineers. In my opinion we are not at the stage in industry where we can consider/expect any developer to think through each implication of each feature they implement Solution: Hire security engineers to think through each implication. Why are we disagreeing? On Sun, Apr 21, 2013 at 12:11:51AM +0100, Benji wrote: Your proposition was that developers will always make mistakes and introduce stupid problems, so a QA team/process is necessary. While I agree that there should be a QA/'audit' at some point, it shouldnt be the stage that is relied on. Applications that are flawed from the design stage onwards will become expenditure blackholes, especially after going through any QA process which should highlight these. Potentially yes, but most of the larger companies appear to already do this. A quick search through google shows that Oracle atleast already have, and/or are actively hiring security engineers involved with Java (for example). Flaws will always pop up and I think we may now be bordering on discussing what counts as negligence in some cases. Your 5-chained-0day-to-code-exec, in my opinion, does not count as negligence and comes from the developer effectively not being a security engineer, but doing the job of a developer. In my opinion we are not at the stage in industry where we can consider/expect any developer to think through each implication of each feature they implement, without a strong security background as much as we may appreciate it. Negligence in my opinion of security vulnerabilities is having obvious format string bugs/buffer overflows when handling user input for example, or incorrect permissions, or just a lack of consideration to obvious problems. Developer training should pick up on the obvious bugs, or atleast give developers an understanding of how to handle users/user input in a safe manner, and know the implications of not doing so. On Sat, Apr 20, 2013 at 11:58 PM, Bryan br...@unhwildhats.com wrote: I think the definition of 'needless staff' highly depends on whether you want 'vulnerable software'. Educating current developers is absolutely a good idea, but still not foolproof. The bottom line is that if you want safe software, you need to invest in proper development. As far as I am concerned, for large companies like Adobe and Oracle, where software bugs in your product have a direct impact on the safety of your customers, that involves hiring specialized staff. ___ 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] VUPEN Security Research - Adobe Flash Player RTMP Data Processing Object Confusion (CVE-2013-2555)
Hahahahahaha. Sorry. Yes, a better idea would be to educate and inform developers. 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/
Re: [Full-disclosure] VUPEN Security Research - Adobe Flash Player RTMP Data Processing Object Confusion (CVE-2013-2555)
The only point that I was trying to make is that there needs to be more of an investement in the security facet of software development, and that if a company is not willing to invest the resources to create a secure product, not to whine when they get hacked. On Sun, Apr 21, 2013 at 12:43:15AM +0100, Benji wrote: Sorry, by flaws, I should have said, *has not prevent bad code/ineffective patches from being pushed out On Sun, Apr 21, 2013 at 12:41 AM, Benji m...@b3nji.com wrote: (For example, http://webcache.googleusercontent.com/search?q=cache:2cXGaaHnqyMJ:www.computerworld.com/s/article/9235954/Researchers_find_critical_vulnerabilities_in_Java_7_Update_11+cd=8hl=enct=clnkgl=uk ) On Sun, Apr 21, 2013 at 12:37 AM, Benji m...@b3nji.com wrote: Because security engineers are different to a QA department you originally suggested, and you seem to be very ideologist about the scenarios. As we've seen, Oracle's Java product has security engineers and this has not prevented flaws. On Sun, Apr 21, 2013 at 12:34 AM, Bryan br...@unhwildhats.com wrote: Your 5-chained-0day-to-code-exec, in my opinion, does not count as negligence and comes from the developer effectively not being a security engineer Solution: Hire security engineers. In my opinion we are not at the stage in industry where we can consider/expect any developer to think through each implication of each feature they implement Solution: Hire security engineers to think through each implication. Why are we disagreeing? ___ 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] VUPEN Security Research - Adobe Flash Player RTMP Data Processing Object Confusion (CVE-2013-2555)
On Sat, 20 Apr 2013 20:02:12 -0400, Bryan said: The only point that I was trying to make is that there needs to be more of an investement in the security facet of software development, and that if a company is not willing to invest the resources to create a secure product, not to whine when they get hacked. Are they allowed to whine if they invest the resources, and still get hacked? pgpp9HBYdgeVe.pgp Description: PGP signature ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
