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: Sun, 21 Apr 2013 00:37:28 +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)

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

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