Re: [Full-disclosure] VUPEN Security Research - Adobe Flash Player RTMP Data Processing Object Confusion (CVE-2013-2555)
It was a perfect example of a largely deployed application which utilises security engineers, and has pushed patches/code which was ineffective. My point was that bugs like that are a lot easier to sort in a design or development stage than after the fact when remediation time is tight, and that a 'QA' process of any type will not make up for developer mistakes. Sent from my iPhone. On 22 Apr 2013, at 07:39, Jeffrey Walton wrote: > On Sat, Apr 20, 2013 at 7:37 PM, Benji 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. > Oracle is probably not a good example since it leaves known flaws in > the code base. > > http://www.h-online.com/security/news/item/Java-7-Update-21-closes-security-holes-and-restricts-applets-1843558.html: > > The warnings for Java applets now come in two types: an applet that > has a valid certificate generates a warning dialog with the Java logo > in it and details of the applet's certificate, but an applet that is > signed with an invalid certificate, is unsigned or self-signed, will > generate a warning with a yellow shield and warning triangle which is > designed to recommend that the applet should not be run. There is a > problem though with the certificate checking; as The H reported in > March, criminals were using revoked certificates as part of their > attacks and the Java runtime was doing nothing to check the validity > of certificates. On the latest update of Java, this has not changed > either; online validation and revocation checks are still off by > default. ___ 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, Apr 20, 2013 at 7:37 PM, Benji 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. Oracle is probably not a good example since it leaves known flaws in the code base. http://www.h-online.com/security/news/item/Java-7-Update-21-closes-security-holes-and-restricts-applets-1843558.html: The warnings for Java applets now come in two types: an applet that has a valid certificate generates a warning dialog with the Java logo in it and details of the applet's certificate, but an applet that is signed with an invalid certificate, is unsigned or self-signed, will generate a warning with a yellow shield and warning triangle which is designed to recommend that the applet should not be run. There is a problem though with the certificate checking; as The H reported in March, criminals were using revoked certificates as part of their attacks and the Java runtime was doing nothing to check the validity of certificates. On the latest update of Java, this has not changed either; online validation and revocation checks are still off by default. ___ 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)
Sure it's acceptable - especially, if you sell the 0-day to agencies who pay a fortune for it... On Fri, Apr 19, 2013 at 10:26 PM, wrote: > VUPEN Security Research 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/ -- just because you're paranoid, don't mean they're not after you... gpgp-fp: 3DB13F197F8A0360814885D1F1F1E2EFAD509AFD skype:rc46fi gplus.to/gregor twitter.com/#/2smart4u ___ 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)
Sure it's acceptable - especially, if you sell the 0-day to agencies who pay a fortune for it... On Fri, Apr 19, 2013 at 10:26 PM, wrote: > VUPEN Security Research 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/ > -- just because you're paranoid, don't mean they're not after you... gpgp-fp: 3DB13F197F8A0360814885D1F1F1E2EFAD509AFD skype:rc46fi gplus.to/gregor twitter.com/#/2smart4u ___ 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)
Guys, There will be always mistakes, thus we, security guys, will always have a job. That's life, that's human nature. The best solution would be to rely as little as possible on humans, as with the use of "safe languages". But yet, there can be functional flaws. Something you can't ask to all companies though: add more processes or hire more people, especially competent ones. Because there is a cost on all that. In some areas, it is even difficult to find a developper on the market, so a decent one or more, a security guy... So in theory, I agree with you, but in practice, it is too idealistic: we have the folks we have and we need business (and small companies taking risks and making errors). - phocean Le 21 avr. 2013 à 07:06, valdis.kletni...@vt.edu a écrit : > 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? > ___ > 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 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/
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 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=8&hl=en&ct=clnk&gl=uk > ) > > On Sun, Apr 21, 2013 at 12:37 AM, Benji 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 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)
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)
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 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=8&hl=en&ct=clnk&gl=uk) > > > On Sun, Apr 21, 2013 at 12:37 AM, Benji 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 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 >>> 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=8&hl=en&ct=clnk&gl=uk) On Sun, Apr 21, 2013 at 12:37 AM, Benji 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 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 >> 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 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 > 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)
"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 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)
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 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 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 > 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)
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 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 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)
(in my opinion) On Sat, Apr 20, 2013 at 11:42 PM, Benji 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 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 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 >> 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 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 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 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 > 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 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 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 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 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 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 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 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, 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 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 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)
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 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)
On 4/20/13, Sergio Alvarez 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" wrote: > >> I was suddenly reminded of this... >> >> http://www.quickmeme.com/meme/3qicaz/ >> >> On Sat, Apr 20, 2013 at 1:05 PM, Joxean Koret >> 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)
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" wrote: > I was suddenly reminded of this... > > http://www.quickmeme.com/meme/3qicaz/ > > On Sat, Apr 20, 2013 at 1:05 PM, Joxean Koret > 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)
Yeah it is when you are in the business of selling exploits. 2013/4/19 > VUPEN Security Research 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)
I was suddenly reminded of this... http://www.quickmeme.com/meme/3qicaz/ On Sat, Apr 20, 2013 at 1:05 PM, Joxean Koret 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] 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)
WOW... that's what happens in bloated organizations with tiers under tiers ... Might be wise to move to another vendor? On Sat, Apr 20, 2013 at 5:26 AM, wrote: > VUPEN Security Research 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/ > -- Robert Q Kim Man with a Van London: http://sparkah.com/guerrilla-marketing-strategies/man-with-a-van-service-london-is-recommended-by-sparkah-strategic/ 2611 S Coast Highway San Diego, CA 92007 310 598 1606 ___ 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)
VUPEN Security Research 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/
