I didn't realize you credited SLINT in the ITS4 paper. Very cool. It isn't often that the academic world credits non-academic research and vice versa. It is one of my pet peeves of the security research community[1].
SLINT scanned source code. It was born out of how we saw black hats doing automated code reviews with scripts that drove grep in interesting ways. The black hat is scanning lots of software source code looking for *any* exploitable bug. A different problem than the white hat needing to find *all* exploitable bugs in a particular piece of code. I find it interesting that the first static analysis came out of the desire to find bugs to exploit software. Same goes for fuzzing if you look at that technology history. White hats have had to vastly improve and productize these techniques lest black hats run rampant using even inferior tools due to the "all bugs vs. anybug" effect. -Chris 1. "Standing on Other's Shoulders", https://www.securityfocus.com/columnists/486 -----Original Message----- From: Gary McGraw [mailto:g...@cigital.com] Sent: Thursday, October 28, 2010 5:08 PM To: Secure Code Mailing List Cc: Jeremy Epstein; Chris Wysopal Subject: Re: [SC-L] informIT: Technology transfer Weld is correct about SLINT which did predate ITS4. We also created a tool called Jslint which even borrowed the slint name from what was then the l0pht <http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?isNumber=19003&arNumber=877869&isnumber=19003&arnumber=877869> (sorry, I don't seem to have a free link to that ancient paper even on the Cigital complete list at http://www.cigital.com/papers/). Back then from what I recall, slint did a basic binary scan. ITS4 and Jslint, on the other hand, were scanning source code. But the notion of looking for vulnerabilities statically was the important bit. Sorry for the oversight Weld, it was not intentional! (In fact, look through the ITS4 paper's refs...) gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com On 10/28/10 3:26 PM, "Jeremy Epstein" <jeremy.j.epst...@gmail.com> wrote: The ITS4 article can be found at http://www.acsac.org/2000/abstracts/78.html - it won the best paper award when it was presented in 2000. (I don't think SLINT was every presented at a professional conference.) And since I'm mentioning ACSAC, the deadline for early registration is coming up on Nov 11 - some really fascinating papers this year, that maybe you'll be discussing 10 years from now ;-). It's at the Four Seasons in Austin Dec 6-10 (and hotel rooms are only $104!) --Jeremy On Thu, Oct 28, 2010 at 3:04 PM, Chris Wysopal <cwyso...@veracode.com> wrote: > > Nice article. There is a piece of this history that predated ITS4 which is > L0pht's SLINT which was in 1998 and demoed to you and John Viega. > > Here was our original description: > > http://web.archive.org/web/19990209122838/http://www.l0pht.com/slint.html > > >From the Feb, 1999 web page: > > <excerpt> > > Source code security analyzers are publicly available in the black hat > community and are being used to scan for exploitable code. SLINT will help > you render the PD wares obsolete." > > What is it? > SLINT is a core product to be sold into an existing GUI development package. > - Helps people be proactive while writing secure code by highlighting > positional hot spots of exploitable routines and poor memory allocations. > - Identifies suspect blocks of code. > - Makes the task of security review more palatable so you don't need > a team of high-level experts to go through megabytes of code. > - Supplies solutions and/or alternatives to problem areas. > - Most security problems could have been fixed at the beginning of > development. Secure applications must start with a secure base. The Best > *BANG* for the buck is to be proactive at the start of program creation > - Easy to implement into existing Y2K code review packages > > What will it examine and on what platforms? > > - Unix/NT > - C, C++ (JAVA in the future) > - elf-32 binaries > - a.out files > - buffer overflows > - improper SetUID of files > - randomness code faults > - race conditions > - incorrect access of memory > - improper flags on critical system calls > - more? > > </excerpt> > > Sounds very familiar. It is almost hard to believe that was 12 years ago. > > SLINT in turn grew out of the black hat community so I won't claim that L0pht > had this idea first, just that we took it to the "consultingware" level. I > like that term because I lived it with SLINT at L0pht and then UnDeveloper > Studio at @stake which has become the commercial static code analysis service > at Veracode. Our technology at Veracode followed a similar track that the > Cigital to Fortify to HP technology has. > > -Chris > > -----Original Message----- > From: sc-l-boun...@securecoding.org [mailto:sc-l-boun...@securecoding.org] On > Behalf Of Gary McGraw > Sent: Tuesday, October 26, 2010 10:14 AM > To: Secure Code Mailing List > Subject: [SC-L] informIT: Technology transfer > > hi sc-l, > > >From time to time a thread or two has popped up on this list discussing how > >we get software security into the main stream. One obvious way to do this > >is through technology transfer. I am particularly proud of the role that > >Cigital has played getting security-focused static analysis out into the > >"main stream." Now that IBM owns Ounce and HP owns Fortify we should see > >significant uptake of the technology worldwide. > > My informIT column this month is a case study that follows a technology from > Cigital Labs, through Kleiner Perkins and Fortify to the mainstream. As you > will see, technology transfer is hard and it takes serious time and effort. > In the case of code scanning technology, the effort took two companies, > millions of dollars, serious silicon valley engineering and ten years. > > Read all about it here: > <http://www.informit.com/articles/article.aspx?p=1648912> > > Your comments and feedback are welcome. > > gem > > company www.cigital.com > podcast www.cigital.com/silverbullet > blog www.cigital.com/justiceleague > book www.swsec.com > > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L@securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates > _______________________________________________ > > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L@securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates > _______________________________________________ > _______________________________________________ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates _______________________________________________
