full-disclosure - Re: VUPEN Security Research - Adobe Flash Player RTMP Data Processing Object Confusion (CVE-2013-2555)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Sat, 20 Apr 2013 23:42:00 +0100
From: Benji <me@...ji.com>
To: Bryan <bryan@...wildhats.com>
Cc: Full-Disclosure <full-disclosure@...ts.grok.org.uk>
Subject: Re: 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 <bryan@...wildhats.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 <me@...ji.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 <bryan@...wildhats.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 <shadown@...il.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/
>

Content of type "text/html" skipped

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/