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]
From: pdt at jackhammer.org (Paul Tinsley)
Subject: Re: Re: <to various comments>EEYE: Microsoft
 ASN.1 ...

Drew Copley wrote:

>Without replying to each troll, individually, I thought maybe some
>people would like to see some answers to some notes.
>  
>
Most of these are from me, so I will personally respond to those that 
apply.  And believe it or not, this is not a troll, I really wanted to 
see people's viewpoints on this subject.  Thats the neat part about us 
not all working at the same company or striving for the same goals, we 
have different viewpoints.  Asking for enumeration of those CAN be for 
purposes other than trolling, if I wanted to troll I would just reload 
the slashdot main page till a new story came out and mention something 
about hot grits and first post.

>These are my own comments, I speak for myself. 
>
>Question: "Why release all of the details"
>  
>
This statement is not an accurate paraphrase, I didn't say why release 
them all.  I said why release them all on day 0 of the patch release.

>Answer: Polls show this is what administrators what. This is one reason
>we do this. Another reason we do this is simple, we use the details
>ourselves. We use the details to create signatures for our vulnerability
>assessment tool and firewall. Security administrators then download
>these signatures and use them to check for patches or to protect systems
>which can not yet be patched.
>  
>
Administrators don't need this crap to fix their boxes, they simply need 
the exploit vectors, the possible mitigation steps, and the potential 
severity of the vulnerability.  No sysadmin should have time, nor care 
about the call made to localalloc, the decoder functions it effects, 
etc...  The pieces that are needed to make a threat assessment and 
develop a mitigation strategy, IMHO, are all in your bulletin, and 
contained in these sections: Systems Affected, Services Affected, 
Software Affected, Description, Severity.  From that it's pretty obvious 
how bad this one can be, knowing that we can't make people stop using 
Outlook in a corporate environment, or stop using Internet Explorer to 
go to several popular sites, or any of the other numerous 3rd party apps 
that are affected by this.  The strategy is simple, patch, patch, patch.

That is something that takes time in a large enterprise where you have 
to worry about the effects it will have on day to day business.  You 
can't just flip a switch and deploy vendor patches the day they come 
out, I think we all know that Microsoft patches do have bugs from time 
to time and knowing how these will affect your "officially supported" 
corporate applications is important.  Reducing the safe margin of time 
that one has to do that IS a problem in my eyes.

>It does not matter if it is eEye you are talking about in this scenario,
>or one of our competitors. This is the "behind the scenes" picture of
>what happens when a patch is released.
>
Show me one competitor that releases such detail at day 0 of patch release.

>
>When we - or our competitors - do not have full details on a
>vulnerability, we have to reverse engineer the patch to do so. And, we
>all do this. 
>  
>
I am sorry that you have to do what you get paid to do.  Would it be an 
unreasonable thing to consider a gentlemans agreement between assessment 
vendors to share network behavioral fingerprints for vulns such as 
these?  The finder still gets credit, the vendor still gets to help his 
clients, and next time he isn't the one to find it he still gets to help 
his clients.  Seems like a decent deal to me...

>So, people complaining about us releasing all of the details... They
>simply are ignorant of what must be done in this process. They like to
>scream and shout about how a worm will be coming and such, nevermind
>that they don't even understand our advisories in the first place.
>
>  
>
Don't hold yourself in such high reguard to believe that people the 
likes of me cannot comprehend your bulletins, you would be wrong.

>And if this does not make it all incredibly clear, let's spell it out
>for them: we can reverse engineer the patches and have to... If virus
>writers want to, they can, too, as well.
>  
>
Tell me that you have seen complex worms recently?  Most if not all of 
them are cobbled together from exploit code the author found on some 
leet mad phat message board and added in some visual basic or visual c 
to tie the whole thing together to get their spam gateway up and 
running.  The average worm writer is not competent enough to reverse 
engineer a ms patch to find the changed code and produce a working 
exploit from it.

[ .. snip .. ]

>Question/Comment: "What is this thing with rapping?"
>
>Answer: We have had these kinds of things in our advisories since we
>started releasing them way back when. 
>
>Derek, at times, feels the need to bust a rhyme. 
>
>You are not going to stop him.
>  
>
Don't plan to, but perception is reality, if you look like a script 
kiddy, it's going to be really really hard for a large company to write 
you a fat check.  I don't know if you noticed but the day of cutsie 
titles are playful antics are a thing of the past, most people have 
gotten back to real business by now.

>And, I have tried. Knives, ropes, pits, strangulation. He is quite wily.
>
[ .. snip .. ]


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ