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]
Message-ID: <CAEJizbaBekZVrcHrjiimnzbg8xZeVkU=_pt94QUCAAVwzjJiwg@mail.gmail.com>
Date: Sun, 21 Apr 2013 00:11:51 +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)

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 <bryan@...wildhats.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 <me@...ji.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 <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?
>

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ