[SC-L] Unreal IRCd backdoor
Very interesting post by Fyodor: http://seclists.org/nmap-dev/2010/q2/826 Gadi. ___ 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 ___
Re: [SC-L] Fully Countering Trusting Trust through Diverse Double-Compiling
Wheeler, David A wrote: Gadi Evron said: David, this is very cool indeed. Thank you for sharing, and a lot of luck! Thanks! I'd like to note in a semi-related fashion that the concept of trusting trust, while in the original paper limited to the compiler case, is a generic concept in security and could go on up and down the chain of trust forever (beyond the compiler), until at some point you take something on blind faith. Actually, I talk about that in the dissertation. First, it is perfectly reasonable to redefine the word "compiler" to include all sorts of components that you might traditionally define as part of the "environment". For example, you could include the entire operating system as well as what we would traditionally define as "compiler". Of course, now you need all of ITS source code, as a different trusted compiler that's able to compile it, as well as time to make it work. The good news is that, once you did that, you'd have then verified that ALL of those executables correspond to their source code. Second, I do not agree that this is BLIND faith. I agree that you must eventually accept SOME set of components as being sufficiently trustworthy. But the idea is to use a separate trusted compiler/environment to verify your original items. At that point, I don't think it's BLIND at all; you hope the original components are okay, but you've also performed a verification step to increase your confidence that this is so. The phrase "trust, but verify" comes to mind :-). Exactly, it is an endless process of trust, as you trust the second system/environment to be secure, or at least without a backdoor. But while I really like the discussion, I don't want to take away from the value of your work. Thanks again for sharing! Gadi. -- Gadi Evron, g...@linuxbox.org. Blog: http://gevron.livejournal.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. ___
Re: [SC-L] Fully Countering Trusting Trust through Diverse Double-Compiling
Wheeler, David A wrote: All - As you know, in the "trusting trust" attack, compilers can be subverted to insert malicious Trojan horses into critical software... including themselves. This turns out to be a nasty attack that's not easy to counter. I've just released my draft PhD dissertation, "Fully Countering Trusting Trust through Diverse Double-Compiling" (DDC), that describes how to counter the "trusting trust" attack. More details, including the dissertation, are here: http://www.dwheeler.com/trusting-trust On November 23, 2009, 1-3pm, I will be giving a public defense of this dissertation. If you're interested, please come! It will be at George Mason University, Fairfax, Virginia, Innovation Hall, room 105. This 2009 dissertation significantly extends my previous 2005 ACSAC paper. For example, I now have a formal proof that DDC is effective (the ACSAC paper only had an informal justification). I also have additional demonstrations, including one with GCC (to show that it scales up) and one with a maliciously corrupted compiler (to show that it really does detect them in the real world). The dissertation is also more general; the ACSAC paper only considered the special case of a "self-parenting" compiler, while the dissertation eliminates that assumption. David, this is very cool indeed. Thank you for sharing, and a lot of luck! I'd like to note in a semi-related fashion that the concept of trusting trust, while in the original paper limited to the compiler case, is a generic concept in security and could go on up and down the chain of trust forever (beyond the compiler), until at some point you take something on blind faith. Gadi. --- David A. Wheeler ___ 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. ___ -- Gadi Evron, g...@linuxbox.org. Blog: http://gevron.livejournal.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. ___
Re: [SC-L] Supply Chain Resiliency Project Assistance
On Sun, 22 Mar 2009, Gary McGraw wrote: > hi sc-l, > > For what it's worth, I am involved in the project with jmr...as is Sammy > Migues. jmr was our BSIMM participant from DTCC. Their software security > initiative is most impressive. I don't know much TOO much about supply chain issues, but I have to admit that the lecture i heard on the subject by Marcus Sachs was highly interesting and opened my eyes. Blessed initiative. Gadi. > gem > > > On 3/22/09 9:08 AM, "Mason Brown" wrote: > > > Jim Routh, CISO at Depository Trust and Clearing Corporation is leading a > project for the Financial Services ISAC. There is a lot of knowledge on > this list and I was hoping you might be willing to offer your thoughts. > Below is the request from Jim. If you have thoughts or data and could > share it, I'll be happy to collate and send back to the list or to anyone > that requests. After he presents it to the FS-ISAC in May, the complete > information will be made public. > > Important project if your organization uses contractors and outsourcers to > design, build or deploy important applications. Jim Routh, CISO at > Depository Trust and Clearing Corporation (and one of the top CISOs in > implementing application security), leads a broad industry team > identifying leading practices in improving supply chain resiliency -- > specifically in the area of procurement for outsourcing software > development and services. They have asked for your help in finding sources > of information in the public domain and/or descriptions of a practice or > control that you have used that actually mitigates one or > more risks. If you have experience or knowledge of security controls and > practices specific to the outsourcing of application development through > service providers please send a note to Mason Brown at mbr...@sans.org. > This can include things like sample contract language or URLs > information/resources you have seen or used. We will provide a summary of > the information to anyone who contributes or expresses and interest in > seeing the results. > > > *** > Action Required: > > Give some thought to helpful information on security controls and > practices specific to the outsourcing of application development work > through service providers that will help improve the resiliency of the > supply chain that may be in two categories: > > 1. Source information in the public domain with reference information on > where to find it (eg: url) > 2. Description of a practice/control along with a summary of the risks > mitigated > > We are striving to create a summary of practices/controls for > consideration for those organizations interested in significantly > increasing their supply chain resiliency and mitigate the risk of sabotage > of supply chain sources. This information along with the survey results > will provide the information security professional with a source of > information enabling him/her to determine the appropriate > practices/controls for his/her organization. > > > > Mason Brown, Director > SANS Institute (www.sans.org) > 865-692-0978 (w) > > > Don't miss SANSFIRE 2009 with the Internet Storm Center! June 13-22 in > Baltimore, MD http://www.sans.org/info/39248 > > "SANS courses are hands-down the best security courses in the industry." - > Scott Hiltis, Bruce Power > > ___ > 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. > ___ > > > ___ > 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. > ___ > ___ 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. ___
Re: [SC-L] Secure Development World ?
On Fri, 14 Mar 2008, Steven M. Christey wrote: > > Gadi, > > All indications are that it was cancelled. Would have been nice if they'd > informed the speakers. Too bad, too - it was looking like it would be a > great conference. They didn't inform me I am speaking, a Google alert did. They informed me it was cancelled, but just a couple of weeks to the conference and the web page doesn't indicate it. So making sure. > > - Steve > > > On Fri, 14 Mar 2008, Gadi Evron wrote: > >> I am trying to understand if this conference is cancelled or not? >> ___ >> 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. >> ___ >> > ___ 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. ___
[SC-L] Secure Development World ?
I am trying to understand if this conference is cancelled or not? ___ 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. ___
Re: [SC-L] MetriCon 2.0 CFP
On Tue, 24 Apr 2007, Gunnar Peterson wrote: > Book is here > > "Security Metrics: Replacing Fear, Uncertainty, and Doubt" by Andrew Jaquith I thought it was about ROSI all over again? Having been to and spoken at several CISO conferences, I stayed away from this book up to now. > http://www.amazon.com/Security-Metrics-Replacing-Uncertainty-Doubt/dp/032134 > 9989 > > I am halfway through and it is excellent so far, will post a review soon. > Not sure how the security industry as we know it will get by without fud. Pretty good! Thank you very much. The problem of teaching security practitioners on how to "speak" without FUD, even if they don't see it as FUD, is just as great. Gadi. > > -gp > > On 4/24/07 7:32 PM, "Gary McGraw" <[EMAIL PROTECTED]> wrote: > > > Plus, check out Andrew Jaquith's excellent book: > > > > -Original Message- > > From: Gunnar Peterson [mailto:[EMAIL PROTECTED] > > Sent: Tue Apr 24 20:14:53 2007 > > To: Secure Mailing List > > Subject: [SC-L] MetriCon 2.0 CFP > > > > Last year's conference, MetriCon 1.0 featured a software security metrics > > track ( http://securitymetrics.org/content/Wiki.jsp?page=Metricon1.0), > > including: > > > > * A Metric for Evaluating Static Analysis Tools - Chess & Tsipenyuk, Fortify > > * An Attack Surface Metric - Manadhata & Wing, Carnegie-Mellon > > * "Good enough" Metrics - Epstein, WebMethods > > * Software Security Patterns and Risk - Heyman & Huygens, U of Leuven > > * Code Metrics - Chandra, Secure Software > > > > -gp > > > > Second Workshop on Security Metrics (MetriCon 2.0) < Call for Papers > > MetriCon 2.0 CFP > > > > August 7, 2007 Boston, MA > > > > Overview > > > > Do you cringe at the subjectivity applied to security in every manner? If > > so, MetriCon 2.0 may be your antidote to change security from an artistic > > "matter of opinion" into an objective, quantifiable science. The time for > > adjectives and adverbs has gone; the time for hard facts and data has come. > > > > MetriCon 2.0 is intended as a forum for lively, practical discussion in the > > area of security metrics. It is a forum for quantifiable approaches and > > results to problems afflicting information security today, with a bias > > towards practical, specific implementations. Topics and presentations will > > be selected for their potential to stimulate discussion in the Workshop. > > > > MetriCon 2.0 will be a one-day event, Tuesday, August 7, 2007, co-located > > with the 16th USENIX Security Symposium in Boston, MA, USA > > (http://www.usenix.org/events/sec07/). Beginning first thing in the morning, > > with meals taken in the meeting room, and extending into the evening. > > Attendance will be by invitation and limited to 60 participants. All > > participants will be expected to "come with findings" and be willing to > > address the group in some fashion, formally or not. Preference given to the > > authors of position papers/presentations who have actual work in progress. > > > > Each presenter will have 10-15 minutes to present his or her idea, followed > > by 15-20 minutes of discussion with the workshop participants. Panels and > > groups of related presentations may be proposed to present different > > approaches to selected topics, and will be steered by what sorts of > > proposals come in response to this Call. > > > > > > Goals and Topics > > > > The goal of the workshop is to stimulate discussion of and thinking about > > security metrics and to do so in ways that lead to realistic, early results > > of lasting value. Potential attendees are invited to submit position papers > > to be shared with all. Such position papers are expected to address security > > metrics in one of the following categories: > > > > Benchmarking > > Empirical Studies > > Metrics Definitions > > Financial Planning > > Security/Risk Modeling > > Tools, Technologies, Tips, and Tricks > > Visualization > > Practical implementations, real world case studies, and detailed models will > > be preferred over broader models or general ideas. > > > > How to Participate > > > > Submit a short position paper or description of work done/ongoing. Your > > submission must be no longer than five(5) paragraphs or presentation slides. > > Author names and affiliations should appear first in/on the submission. > > Submissions may be in PDF, PowerPoint, HTML, or plaintext email and must be > > submitted to MetriCon AT securitymetrics.org. > > > > Presenters will be notified of acceptance by June 22, 2007 and expected to > > provide materials for distribution by July 22, 2007. All slides and position > > papers will be made available to participants at the workshop. No formal > > proceedings are intended. Plagiarism constitutes dishonesty. The organizers > > of this Workshop as well as USENIX prohibit these practices and will take > > appropriate action if dishonesty of this sort is found. Submission of > > recent, previously published work as well as simu
[SC-L] [fuzzing] the future of fuzzing [was: Rcov] (fwd)
I didn't want to cross-post to another list, but sending here if the
moderator finds this post useful.
-- Forwarded message --
Date: Mon, 26 Mar 2007 19:05:58 -0500 (CDT)
From: Gadi Evron <[EMAIL PROTECTED]>
To: Kowsik <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED], dailydave@lists.immunitysec.com
Subject: [fuzzing] the future of fuzzing [was: Rcov]
On Mon, 26 Mar 2007, Kowsik wrote:
> We just released rcov-0.1, an interactive/incremental code coverage
> tool to assist in building effective fuzzers.
>
> Quick summary:
>
> - It's a WEBrick browser-based application (ruby)
> - Uses gcov's notes/data files to get at blocks and function summaries
> - Interactively/incrementally shows the coverage information while fuzzing
> - Uses ctags to cross reference functions/prototypes/definitions/macros
Hi Kowsik, thanks for this.
I have a few notes though, as I believe this can be taken much further
(at least my studies so far show that).
We have three levels or layers (depends on approach):
1. Building better fuzzers (which you cover).
2. Helping the fuzzing process, fuzzing better.
3. Making the process of finding the actual vulnerability once an
indication is found (a successful test case, or as they say in QA, a
passing one) easier.
Several folks in the past few months have said that fuzzing isn't new and
has been done for years - that much is true.
Some folks also said that fuzzing is as simple as it gets and has no where
left to evolve. That is indeed very much false.
Code coverage, static analysis, run-time analysis.. etc. all have a place
in the future of fuzzing.
I see fuzzers development in coming years as changing the term "dumb
fuzzing" to mean today's protocol-based smart fuzzing, and "smart
fuzzing" being about what interactive changes are happening as you fuzz.
The most that we see today (in most cases) is the engine running
undisturbed, while the monitor (if such even exists) being a simple
debugger.
Evolving host and network monitoring to use profiling technologies, map
functions and paths, watch for memory issues, etc. is fast coming.
Today, changing the action of a fuzzer as it is running is difficult
(there is no real Driver, just an Engine). A simple example for this
evolution could be watching for CPU uage. If the CPU usage spikes it could
mean:
1. We are sending too many requests per second - we should slow down the
engine.
2. (if for the thread itself) We are on to something, we should explore
this attack (likely 1 "attacks" we went through) or adjust to a
different fuzzing engine to explore that particular section of the
program (as we mapped it - code coverage again).
The two don't easily work together, not to mention even stopping a fuzzer,
rewinding it or God forbid running a different one at the same time (on
the same instance anyway).
Which brings us to distributed fuzzing... but that's a whole
different subject yet again.
Fuzzing has a long way to go, and we didn't even really start to explore
full intergration with static analysis tools (other than with results).
We had a discussion on the fuzzing mailing list recently about genetic
fuzzing, but I dam not really a math geek. Jared can explain that one
better... and so on.
All that before we explore uses for fuzzing outside of the development
cycle (mostly security QA) and vulnerability research, which is with
client-side testing. Perhaps fuzzers will help us force the hand of
software vendors to develop more robust and secure code.
Working for a fuzzing vendor I am only too familiar with the Turing
halting problem and seeking reality in the midst of eternal runs, but the
most interesting thing I found in the past few months (which wasn't
technical) is the clash of cultures between QA engineers and Security
professionals. It will be very interesting to see where we end up.
Thanks,
Gadi.
--
"beepbeep it, i leave work, stop reading sec lists and im still hearing
gadi"
- HD Moore to Gadi Evron on IM, on Gadi's interview on npr, March 2007.
___
fuzzing mailing list
[EMAIL PROTECTED]
http://www.whitestar.linuxbox.org/mailman/listinfo/fuzzing
___
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.
___
Re: [SC-L] Full Disclosure: Fuzzled - Perl fuzzing framework
On Mon, 26 Mar 2007, Kenneth Van Wyk wrote: > FYI, I saw this tool announcement and thought some folks here might > find it useful. It's a free perl-based fuzzing framework written by > Tim Brown. Follow the link to find the download site. > > http://seclists.org/fulldisclosure/2007/Mar/0415.html > Another interesting open source fuzzer from recent months is TAOF. > Cheers, > > Ken > - > Kenneth R. van Wyk > SC-L Moderator > KRvW Associates, LLC > http://www.KRvW.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. ___
Re: [SC-L] Economics of Software Vulnerabilities
On Tue, 13 Mar 2007, Gary McGraw wrote: > In my opinion, though fuzz testing is certainly a useful technique (we've > used it in hardware verification for years), any certification based solely > on fuzz testing for security would be ludicrous. Fuzz testing is not a > silver bullet. Fuzzing is indeed, most definitely, not a or the silver bullet, nor should testing be based on itsolely. What it does provide us with is a measurable fashion by which we can reliably test the: 1. Stability 2. Programming quality 3. Robustness Of software, to a level which is much higher than employing several reverse engineers and test engineers (not to say just examining vulnerability history on the bugtraq archive). Further, if not by certification, fuzzing has already shown it can pressure companies to use software development lifecycle methodologies and that way enforcing (encouraging?) better security with "partners" (read Microsoft). Fuzzing has also shown that it can be used to force vendors who sell to you to indeed be "tested" by certain products (read large Telcos). Although I am unsure if this approach holds water. The re-emergence of this field beyond rubber stamp certifications or very costly certifications, is something I see as very positive. That, of course, if not a or the sulver bullet in any way, either, but maybe we will see less input validation bugs around and will start facing logical flaws that will boggle our minds. Personal opinion: enough with buffer overflows already, no? :) > The biggest stumbling block for software certification is variability in > final environment. That makes sense, but I figure if we can eliminate some more by a factor in our testing environment(s), all the better. > gem Gadi. -- "beepbeep it, i leave work, stop reading sec lists and im still hearing gadi" - HD Moore to Gadi Evron on IM, on Gadi's interview on npr, March 2007. ___ 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. ___
Re: [SC-L] Economics of Software Vulnerabilities
On Mon, 12 Mar 2007, Crispin Cowan wrote: > Ed Reed wrote: > > For a long time I thought that software product liability would > > eventually be forced onto developers in response to their long-term > > failure to take responsibility for their shoddy code. I was mistaken. > > The pool of producers (i.e., the software industry) is probably too > > small for such blunt economic policy to work. > > > I'm not sure about the size of the pool. I think it is more about the > amount of leverage that can be put on software: > > * It is trivial for some guy in a basement to produce a popular > piece of open source software, which ends up being used as a > controlling piece of a nuclear reactor, jet airplane, or > automobile, and when it fails, $millions or $billions of damages > result. The software author has no where near the resources to pay > the damage, or even the insurance premiums on the potential damage. > * In contrast, with physical stuff it is usually the case that the > ability to cause huge damage requires huge capital in the first > place, such as building nuclear reactors, jet planes, and cars. > > With this kind of leverage, the software producers don't have the > resources to take responsibility, and so strict liability applied to > authors reduces to "don't produce software" unless, possibly, you work > for a very large corporation with deep pockets. Even then, corporate > bean counters would likely prevent you from writing any software because > the potential liability is so large. > > > It appears, now, that producers will not be regulated, but rather users > > and consumers. SOX, HIPAA, BASEL II, etc. are all about regulating > > already well-established business practices that just happen to be > > incorporating more software into their operations. > > > Much like the gun industry. Powerful, deadly tools that, if used > inappropriately, can cause huge damage. Indeed, and I found your posts enlightening. Still, today an alternative presentsitself in the now more likely realm of software security certification and testing. It has become more easier and potentially regulated now that fuzzers have become: 1. Good enough. 2. Measurable. 3. Widely accessible. Gadi. ___ 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. ___
Re: [SC-L] Dr. Dobb's | The Truth About Software Security | January 20, 2007
On Tue, 30 Jan 2007, Michael S Hines wrote: > One examining only source code will miss any errors or problems that may be > introduced by the compiler or linker. As Symantec says - working with the > object code is working at the level the attackers work. > > Of course one would have to verify the object code made public is the same > object code that was analyzed/verified. Otherwise you could get the case > where the code was advertised as 'checked' and it still have a > vulnerability.Of course that could happen anyway - as the process > probabily isn't perfect (thought much better than nothing). > > Not all compilers or linkers are perfect either. > > There is only one way to get it right, yet so many ways to get it wrong. One question which would be very interesting is whether this is just static analysis (which of course leads to other questions) or if this is done while the binary is running. Gadi. > > Mike Hines > > - > Michael S Hines > [EMAIL PROTECTED] > > > _ > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Kenneth Van Wyk > Sent: Tuesday, January 30, 2007 5:25 AM > To: Secure Coding > Subject: [SC-L] Dr. Dobb's | The Truth About Software Security | January > 20,2007 > > > FYI, there's an interesting article on ddj.com about a Symantec's new > "Veracode" binary code analysis service. > > http://www.ddj.com/dept/security/196902326 > > Among other things, the article says, "Veracode clients send a compiled > version of the software they want analyzed over the Internet and within 72 > hours receive a Web-based report explaining--and prioritizing--its security > flaws." > > > Any SC-Lers have any first-hand experience with Veracode that they're > willing to share here? Opinions? > > > Cheers, > > > Ken > > - > Kenneth R. van Wyk > SC-L Moderator > KRvW Associates, LLC > http://www.KRvW.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. ___
[SC-L] fuzzing the corporate world
After a couple of folks said they liked it, I figured it is on-topic
enough to send it here. This is my lecture from CCC, I hope you like it
(I swear in it.. it's defcon-like, be warned PG-13).
It basically describes fuzzing and how it can be/is implemented in the
corporate world/as part of the development process/as certification/as
testing... etc. and how a fuzzer can be built to fit what the corporate
world is looking for.
This is not a technical lecture in any way - so skip it if that's what you
are looking for. We do cover the basics of black box testing with fuzzing,
though.
:)
http://media.hojann.net/23C3/23C3-1758-en-fuzzing_corporate_world.m4v
http://fsmpi.uni-bayreuth.de/~pw/23c3/23C3-1758-en-fuzzing_corporate_world.m4v
>From the talk description:
http://events.ccc.de/congress/2006/Fahrplan/events/1758.en.html
(an updated PDF of the presentation should be there soon)
Fuzzing in the corporate world
The use of fuzzing in the corporate world over the years and recent
implementation of fuzzing tools into the development cycle and as a
requirement before purchase
We will discuss fuzzing uses by software vendors and in the corporate
world, for security auditing ("fuzzing before release") and third party
testing ("fuzzing before purchase"). We will look at what contributed to
this change in the use of fuzzing tools from home-grown hacking tools to
commercial products, as well as how these organizations implement fuzzing
into their development cycle.
Fuzzing has been used for a long time in the hacker scene. Mostly, these
tools have been home-grown. In the recent year, several commercial fuzzing
tools appeared. These in turn are now utilized by organizations in the
development cycle under the moto of "fuzzing before release", or "find the
vulnerability before hackers do". Another interesting and somewhat
unexpected development in the field is that end-clients are the largest
consumers of advanced fuzzing technology, performing tests on software
before purchase. Further, some large telcos and financial institutions now
demand for products to be certified (even if not by an official seal) by
fuzzing products which they authorize.
Is fuzzing finally a solution to reduce vulnerabilities in products rather
than just later discover them? How is it used by these corporations and
third-party organizations? Some methodologies as well as examples will be
presented, and we will also try to look into what the future holds.
Gadi.
___
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.
___
[SC-L] Luis Miras on automated exploit detection in binaries at CCC
CCC was amazing, and here is the video for one of the lectures. http://video.google.com/videoplay?docid=-5897236579900914407&q=23c3 ___ 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. ___
[SC-L] it's Y2K, no, it's 32 bit unix time, no, it's slashdot!
[X-posted to the funsec mailing list] http://slashdot.org/articles/06/11/09/1534204.shtml "2^24 comments ought to be enough for anyone" -- CmdrTaco Slashdot Posting Bug Infuriates Haggard Admins Posted by CmdrTaco on Thursday November 09, @10:45AM from the this-is-never-good dept. Slashdot.org Last night we crossed over 16,777,216 comments in the database. The wise amongst you might note that this number is 2^24, or in MySQLese an unsigned mediumint. Unfortunately, like 5 years ago we changed our primary keys in the comment table to unsigned int (32 bits, or 4.1 billion) but neglected to change the index that handles parents. We're awesome! Fixing is a simple ALTER TABLE statement... but on a table that is 16 million rows long, our system will take 3+ hours to do it, during which time there can be no posting. So today, we're disabling threading and will enable it again later tonight. Sorry for the inconvenience. We shall flog ourselves appropriately. ___ 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
Re: [SC-L] Fwd: re-writing college books - erm.. ahm...
On Tue, 7 Nov 2006, Matt Bishop wrote: > Folks, > > A comment based on an idea we tried here. > > > Well, I never recieved any replies here on what's already being > > done.. so > > now, I am asking for ideas on how we can approach schools. What's > > needed, > > in order for basic CS classes to have a security orientation? > > Ideally, I agree with the sentiment but would quarrel with the > wording :-). On a practical level, I think this is very unlikely to > happen. For example, one problem is those classes are already > overloaded with how to program *plus* language stuff. You can only do > so much in 10 or 15 weeks (depending on whether you're on the quarter > or semester system). > > An alternative to focusing on the introductory classes is to provide > support for programming throughout the curriculum. But the big > problem is overloaded classes--we try to teach too much material now. > Telling an algorithms instructor she also needs to teach some > security will fail on at least two counts: (1) "How do I teach the > required course material *plus* security?" (2) "How do I learn enough > about security to know what to teach and how to teach it? And where > do I find the time to learn this?" So I don't think adding more > material to existing classes will work. > > So let's take a page from English departments and/or law schools. > Both have writing clinics--they are separate from classes, and > provide reviews of written papers before those papers are turned in. > The ones I'm familiar with do *not* address content, but they *do* > address mechanics (grammar, punctuation, etc.) and expression--does > the writing make sense, is it well organized, and so forth. Why not > establish something similar for programming? > > You could work this in a number of ways. The one we've tried here was > to require the students to write the program and then meet with > someone working in the clinic. The clinician went through the program > with the student, pointed out potential problems and bad programming > practices, and (when appropriate) security issues. No grading > occurred, but the student could rewrite the program to fix the > problems pointed out (and others that the student found--the > clinician did not try to find all the problems, just enough to show > the student what types of problems were there). > > We did some very informal testing, and the results were promising. If > anyone's interested, we did a write-up of it; see: > > http://nob.cs.ucdavis.edu/~bishop/papers/2006-cisse-2/ > > I need to emphasize the results are informal because we weren't > educational metricians. Our next step (assuming we can get the > funding) will be to devise formal metrics and do some more rigorous > measurements to see how well the clinic works. > > The interesting point about the clinic is that it appeared to be > effective at both introductory and upper division levels, provided > the students used it. It also would provide reinforcement throughout > the student's undergraduate education, and give the student more of a > chance to absorb good programming practices than do one or two > classes that focus on those aspects of programming. > > Just a thought I am not sure I understand all you wrote yet. So I may ask you more later. Let me ask you this, the basic courses such as C (pascal, c++, whatever) are used to teach other things along the line. Won't changing that course be a great start? Further, if not much can be changed with time constraints, what would it "cost, for example, to teach people to check their input, or set boundaries? With references to more material. Gadi. > > Matt > > == > Matt Bishop > Department of Computer Science > University of California at Davis > One Shields Ave. > Davis, CA 95616-8562 > United States of America > > phone: +1 530 752 8060 > fax: +1 530 752 4767 > web: http://seclab.cs.ucdavis.edu/~bishop > > > ___ 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
Re: [SC-L] Fwd: re-writing college books - erm.. ahm...
On Wed, 8 Nov 2006, Robin Sheat wrote: > > It is important to note that there is no goal of teaching students to go off > and be safe programmers. Computer science is seen to a reasonable extent to > be a theoretical persuit. Algorithms are covered, GC methods, heuristical > searchs, and so on. That many students from this tend to go off and become > programmers is almost seen the same as if they went off and became plumbers, > just much more common. They are, of course, expected to hang around and > become academics ;) CS degree brings you to the academic world, and makes a scietist of you. Many go that route to become, coders. You don't teach programming at an EDU. As they are supposed to be scientists, I see no reason why this training can't be done with correct programming in mind. Teaching people how to code wrongly just to teach them later how it sid one correctly and slower, is a silly idea. It's not a bad idea as a conentrated specialized course, it is a silly idea as far as the actual original teaching goes, that is equivalent to patches rather than no vulnerabilities. Gadi. ___ 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
Re: [SC-L] Fwd: re-writing college books - erm.. ahm...
On Mon, 6 Nov 2006, Julie J.C.H. Ryan wrote: > Folks, I've been forwarding select messages from this listserv to my > nephews, who are undergrads in CS at some fairly reknown > universities, which shall remain nameless cause it would embarrass > the heck out of them to have the following sentiment aired.. > > Begin forwarded message: > > > > > ya, as per one of your previous emails, we are still taught to use > > only printf and random stuff like that. printf was even incorporated > > into java 1.5 because "it was so good." But right now I think we are > > really just learning base algorithms and ideas rather than security > > practices. Hell, I talked to my student advisor and apparently I can't > > even take security courses till I'm working on a masters degree. Well, I never recieved any replies here on what's already being done.. so now, I am asking for ideas on how we can approach schools. What's needed, in order for basic CS classes to have a security orientation? Gadi. ___ 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
Re: [SC-L] re-writing college books - erm.. ahm...
On Sun, 5 Nov 2006, Leichter, Jerry wrote: > Much as I agree with many of the sentiments expressed in this discussion, > there's a certain air of unreality to it. While software has it's own > set of problems, it's not the first engineered artifact with security > implications in the history of the world. Bridges and buildings > regularly collapsed. (In the Egyptian desert, you can still see a > pyramid that was built too aggressively - every designer wanted to > build higher and steeper than his predecessor - and collapsed before > it was finished.) Steam boilers exploded. Steel linings on wooden > railroad tracks stripped of, flew through the floors of passing cars, > and killed people. Electrical systems regularly caused fires. > > How do we keep such traditional artifacts safe? It's not by writing > introductory texts with details of safety margins, how to analyze the > strength of materials, how to include a crowbar in a power supply. > What you *may* get in an introductory course is the notion that there > are standards, that when it comes time for you to actually design > stuff you'll have to know and follow them, and that if you don't you're > likely to end up at best unemployed and possibly in jail when your > "creativity" kills someone. > > In software, we have only the beginnings of such standards. We > teach and encourage an attitude in which every last bit of the > software is a valid place to exercise your creativity, for better > or (for most people, most of the time) worse. With no established > standards, we have no way to push back on managers and marketing > guys and such who insist that something must be shipped by the > end of the week, handle 100 clients at a time, have no more tha > 1 second response time, and run on some old 486 with 2 MB of memory. > > I don't want to get into the morass of licensing. It's a fact that > licensing is heavily intertwined with standard-setting in many > older fields, but not in all of them, and there's no obvious inherent > reason why it has to be. > > The efforts to write down "best practices" at CERT are very important, > but also very preliminary. As it stands, what we have to offer > are analogous to best practices for using saws and hammers and > such - not best practices for determining floor loadings, appropriate > beam strengths, safe fire evacuation routes. > > Every little bit helps, but a look at history shows us just how > little we really have to offer as yet. Well said, and quite right. A few pointers though. A bridge is a single-purpose device. A watch is a simple purpose computer, as was the Enigma machine, if we can call it such. Multi-purpose computers or programmable computers are where our problems start. Anyone can DO and create. One simply has to sit in front of a keyboard and screen and make it happen.. As such, even if built well, the computer is programmable, and thus at risk. Gadi. > -- Jerry > > > ___ > 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 > ___ 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
Re: [SC-L] re-writing college books - erm.. ahm...
On Sun, 29 Oct 2006, Robert C. Seacord wrote: > Gadi, > > I feel like I've been here before, but I'll give it another shot anyway. > > > Okay, than let's make some progress: > > 1. Where and who is currently involved with doing this? > > 2. What are they doing? > > 3. Can we use their experience to make it a larger success? > > 4. How do we begin doing something large-scale? > > The Secure Coding Initiative at CERT has a web site at > www.securecoding.cert.org. The purpose of this site is to collect > secure coding recommendations and rules for various programming > languages. Our initial focus has been C and C++, but we are willing and > interested in expanding this effort to other programming languages > provided that we can find someone to manage the efforts. > > The C and C++ material on the site will be used as supplemental material > to the Addison-Wesley book "Secure Coding in C and C++" in a "Secure > Programming" course I am teaching this Spring at CMU (so it is being > used to teach, as well as being a commercial and government resource). > I am also working with other instructors at other educational > institutions to develop secure coding curriculum. We misunderstand each other. I am not speaking of a secure coding book, I am speaking of "Introduction to Computer Science" and "The C programming Language". If we can use what you have already worked on to supplament these courses, then all for the better! > > We have had significant community effort in the development of these > secure coding standard practices so far, but we can use all the help we > can get. If you would like to get involved, go the sight, sign up, and > start reviewing the material. If you are qualified and would like to > edit the material directly, send me email and I will grant you edit > permissions. I doubt I am that much of a good coder anymore. > > I think having a body of knowledge that identifies insecure coding > practices and provides secure alternatives is a good first start, and > not as easy as it sounds. Agreed! Nice work on all that! > > - > > I also had another thought about improving the quality of code examples > in texts. I know my publisher (Addison-Wesley), and I'm sure others, > are very concerned about quality. I could ask my editor if they would > be willing to make sure that someone with a security background reviewed > any new programming texts. If we can come up with a list of subject > matter experts willing to review new texts, I'm guessing they would be > very happy to have our feedback. That sounds like a very good idea! I am sure many would agree to get some extra cash for reviewing, thing is, that doesn't pay very well. > > rCs > > ___ 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
Re: [SC-L] re-writing college books - erm.. ahm...
On Sat, 28 Oct 2006, Crispin Cowan wrote: > Gadi Evron wrote: > > So, "dump C", "Use SML", "What secure coding classes are you doing?" and > > "we are already doing it!!" are the responses I got when I started this > > thread. > > > What did you expect from whining about the generally poor quality of > software? :) > > > Can someone mention again why re-writing the main often-used and probably > > less than 3 mostly-used basic programming books is a bad idea? > > > Uh ... 'cause I question the assertion that there are 3 mostly-used > basic programming books. I suspect it is more like 78 mostly used books. > More importantly, if there are 3 mostly used books, then there are 78 > more behind them vying for those 3 slots, and they all have the same > problems. If you write a new book, then you just join the pool of 78, > and you have the impact of a drop in the bucket. > > Worse, we are talking about correctness here. Correctness is hard, and > correctness on a large scale is harder. I doubt that even a concerted > effort at a "correct" book on intro to programming would manage to > actually be correct any time before the 3rd edition, 10 years from now. > > Seeking perfect correctness as an approach to security is a fool's > errand. Security is designing systems that can tolerate imperfect software. For argument sake, let's assume there are 100. How about campaigning for a secure coding chapter to be added to these semester, erm, world-wide? Nothing is ever easy, but we have to start somewhere. I don't see why this is a bad idea. Yes, it takes time. Yes, it will have a much bigger impact. Gadi. > > Crispin > > -- > Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ > Director of Software Engineering, Novell http://novell.com > Hack: adroit engineering solution to an unanticipated problem > Hacker: one who is adroit at pounding round pegs into square holes > ___ 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
Re: [SC-L] re-writing college books - erm.. ahm...
On Sat, 28 Oct 2006, Crispin Cowan wrote: > Gadi Evron wrote: > > Nothing is ever easy, but we have to start somewhere. I don't see why this > > is a bad idea. Yes, it takes time. Yes, it will have a much bigger impact. > > > It is not a bad idea. But it clearly is not sufficient. Why are you Now we're talking. Not sufficient I am game with. Nothing ever is, it is one more thing to do. > assuming that it is not already being tried? The problem is that it is I am assuming most higher education institutions in the world do not have it done. > being tried with the usual degree of effectiveness, i.e. unevenly. > Saying "lets try it" is redundant, because that is already going on, > just not enough. To make it more, one would have to convince the people > who are currently not doing it, or doing it badly, to do better, and > they (by definition) are not listening. Okay, than let's make some progress: 1. Where and who is currently involved with doing this? 2. What are they doing? 3. Can we use their experience to make it a larger success? 4. How do we begin doing something large-scale? Gadi. > > Crispin > > -- > Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ > Director of Software Engineering, Novell http://novell.com > Hack: adroit engineering solution to an unanticipated problem > Hacker: one who is adroit at pounding round pegs into square holes > ___ 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
Re: [SC-L] re-writing college books - erm.. ahm...
On Tue, 24 Oct 2006, Crispin Cowan wrote: > Sure, there are likely to be ways in which SML is better than C# or > Java. However, in security, the perfect is all to often the enemy of the > good-enough. The big community hears security people talk about the high > security approach that security geeks really want, consider the costs, > and go back to doing things the old way, and ignore the security people. > If security people instead pitch something that is feasible and makes > the situation better, instead of asking for the moon, we will make more > progress. > > Crispin (not directed at you, Crispin) So, "dump C", "Use SML", "What secure coding classes are you doing?" and "we are already doing it!!" are the responses I got when I started this thread. Can someone mention again why re-writing the main often-used and probably less than 3 mostly-used basic programming books is a bad idea? All of us will still have a job in 5 years if we do this, even in 25. I promise. Gadi. ___ 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
Re: [SC-L] re-writing college books [was: Re: A banner year for software bugs | Tech News on ZDNet]
On Wed, 11 Oct 2006, Gary McGraw wrote: > We're working on it! The problem is not simply a book. Great! What are you guys doing? What more can be done? There are quite a few of us willing to help, and I figure, starting with the books future programmers learn from is not a bad idea. This community is perfect for this job. Gadi. > > gem > > -Original Message----- > From: Gadi Evron [mailto:[EMAIL PROTECTED] > Sent: Wed Oct 11 20:58:12 2006 > To: Kenneth Van Wyk > Cc: Secure Coding > Subject: [SC-L] re-writing college books [was: Re: A banner year for > software bugs | Tech News on ZDNet] > > So, how can we edit current basic programming college books to present > secure code, a couple of words of the correct way of doing things, and a > whole new chapter on secure coding (which may be redudndent?) > > How do we start? > > Some Whiley book for introduction to CS? > > Any volunteers to get this on the road? > > Gadi. > > On Wed, 11 Oct 2006, Kenneth Van Wyk wrote: > > > So here's a lovely statistic for the software community to hang its > > hat on: > > > > http://news.zdnet.com/2100-1009_22-6124541.html?tag=zdfd.newsfeed > > > > Among other things, the article says, "Atlanta-based ISS, which is > > being acquired by IBM, predicts there will be a 41 percent increase > > in confirmed security faults in software compared with 2005. That > > year, in its own turn, saw a 37 percent rise over 2004." > > > > Of course, the real losers in this are the software users, who have > > to deal with the never ending onslaught of bugs and patches from > > their vendors. We've just _got_ to do better, IMHO, and automating > > the patch process is not the answer. > > > > Cheers, > > > > Ken > > - > > Kenneth R. van Wyk > > KRvW Associates, LLC > > http://www.KRvW.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 > > > > > > This electronic message transmission contains information that may be > confidential or privileged. The information contained herein is intended > solely for the recipient and use by any other party is not authorized. If > you are not the intended recipient (or otherwise authorized to receive this > message by the intended recipient), any disclosure, copying, distribution or > use of the contents of the information is prohibited. If you have received > this electronic message transmission in error, please contact the sender by > reply email and delete all copies of this message. Cigital, Inc. accepts no > responsibility for any loss or damage resulting directly or indirectly from > the use of this email or its contents. > Thank You. > > ___ 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] re-writing college books [was: Re: A banner year for software bugs | Tech News on ZDNet]
So, how can we edit current basic programming college books to present secure code, a couple of words of the correct way of doing things, and a whole new chapter on secure coding (which may be redudndent?) How do we start? Some Whiley book for introduction to CS? Any volunteers to get this on the road? Gadi. On Wed, 11 Oct 2006, Kenneth Van Wyk wrote: > So here's a lovely statistic for the software community to hang its > hat on: > > http://news.zdnet.com/2100-1009_22-6124541.html?tag=zdfd.newsfeed > > Among other things, the article says, "Atlanta-based ISS, which is > being acquired by IBM, predicts there will be a 41 percent increase > in confirmed security faults in software compared with 2005. That > year, in its own turn, saw a 37 percent rise over 2004." > > Of course, the real losers in this are the software users, who have > to deal with the never ending onslaught of bugs and patches from > their vendors. We've just _got_ to do better, IMHO, and automating > the patch process is not the answer. > > Cheers, > > Ken > - > Kenneth R. van Wyk > KRvW Associates, LLC > http://www.KRvW.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
Re: [SC-L] Google code search games
On Sun, 8 Oct 2006, Ron Forrester wrote: > WSDL: > > http://www.google.com/codesearch?hl=en&lr=&q=file%3A.wsdl%24+transfer&btnG=Search I am still updating the main post with new search regex as I find them, all the time: http://blogs.securiteam.com/index.php/archives/663 Some other fun was noted on the daily WTF, where the do more funny searches: http://thedailywtf.com/forums/thread/94630.aspx > > > On 10/5/06, Gadi Evron <[EMAIL PROTECTED]> wrote: > > > playing with Google Code Search, as Lev Toger just wrote: > > > > > > Google released a code search engine to catch up with Krugle, Koders, and > > > Codease. > > > > > > Like most of the other Google?s tools it can be easily abused for hacking > > > :) > > > -- > rjf& > ___ > 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 > ___ 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
Re: [SC-L] Google code search games
Another guy just wrote some more fun keyw ords to search for: http://blogs.securiteam.com/index.php/archives/661 On Thu, 5 Oct 2006, Gadi Evron wrote: > playing with Google Code Search, as Lev Toger just wrote: > > Google released a code search engine to catch up with Krugle, Koders, and > Codease. > > Like most of the other Google?s tools it can be easily abused for hacking > :) > > To find undisclosed vulnerabilities pass over this code: > > http://www.google.com/codesearch?q=ugly%7Chack%7Cfixme > > Or some other interesting combination (Use your favorite ugly code > comment). > - > > http://blogs.securiteam.com/index.php/archives/659 > > SO... ugly? dirty hack? > > Gadi. > > ___ 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] (no subject)
playing with Google Code Search, as Lev Toger just wrote: Google released a code search engine to catch up with Krugle, Koders, and Codease. Like most of the other Google?s tools it can be easily abused for hacking :) To find undisclosed vulnerabilities pass over this code: http://www.google.com/codesearch?q=ugly%7Chack%7Cfixme Or some other interesting combination (Use your favorite ugly code comment). - http://blogs.securiteam.com/index.php/archives/659 SO... ugly? dirty hack? Gadi. ___ 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
Re: [SC-L] Web Services vs. Minimizing Attack Surface
On Wed, 16 Aug 2006, mikeiscool wrote: > On 8/16/06, John Wilander <[EMAIL PROTECTED]> wrote: > > Thanks for all the replies so far! I would just like to comment on > > Holger Peine's and Mike Hines' viewpoints. > > > > [EMAIL PROTECTED] wrote: > > > I don't see a conflict here: A web service (just as any > > > network-accessible > > > service, no matter whether programmed using sockets, Java RMI, SOAP or > > > whatever) is _intended_ to provide some function to the outside world, > > > so you have to open _some_ door into your system. The advice about > > > minimizing the attack surface is about not opening any doors you don't > > > really need (or worse, didn't even intend to open). > > > > As you say, any kind of system is _intended_ to provide some function. > > But security bugs often hide in unintended, undocumented or unknown > > functionality. By increasing the attack surface you also increase the > > risk of adding unknown functions. > > > > Mike Hines commented on web services running everything through port 80 > > (HTTP) as negating "... any value of firewalls and most likely intrusion > > detection systems". Indeed, web services tunnel a lot of functionality > > through port 80, effectively hiding it from many system monitoring > > defense measures. The security will rely on validating SOAP envelopes > > and prevention at the application/run-time system level. It seems to me > > like a huge burden. > > A huge burden or a huge benefit? You can validate everything in one > spot, and maybe even solve problems in one spot. > > Imagine if everything went into the same system; thereby suggesting > that all attacks would be similar (i.e. all attacks against the soap > parsers of various apps, or something). If it all goes in one hole, > you can fix it once with your IDS, or whatever acronym you have > installed. > > You seem to be saying that any given app i want to write, and have > publically accessible, I should write to accept connections on another > port, or find another channel to operate on (maybe through a website > app dll calls, or something). > > But then, if we do that, we have to re-write everything each time. > Doesn't make alot of sense ... You do realize you just described the Internet, right? Gadi. > > > > Regards, John > > > -- mic > ___ > 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 > ___ 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
Re: [SC-L] Web Services vs. Minimizing Attack Surface
ou get to play with the code, in some cases anyway.Other than that and the fact the code runs, mostly, locally, there is no difference. The one major different is that with some services, the vulnerability is local as everybody builds their own. The main issue here is that web services allow for easy access to the machine, and for access to many third party and unrelated scripts and modules that will not be accessible by most other programs, once already connected. Gadi. On Tue, 15 Aug 2006 [EMAIL PROTECTED] wrote: > > [mailto:[EMAIL PROTECTED] On Behalf Of John Wilander > > Sent: Dienstag, 15. August 2006 10:03 > > Subject: [SC-L] Web Services vs. Minimizing Attack Surface > > > > Hi! > > > > The security principle of minimizing your attack surface > > (Writing Secure > > Code, 2nd Ed.) is all about minimizing open sockets, rpc endpoints, > > named pipes etc. that facilitate network communication between > > applications. Web services and Service Oriented Architecture on the > > other hand are all about exposing functionality to offer > > interoperability. > > I don't see a conflict here: A web service (just as any > network-accessible > service, no matter whether programmed using sockets, Java RMI, SOAP or > whatever) is _intended_ to provide some function to the outside world, > so you have to open _some_ door into your system. The advice about > minimizing the attack surface is about not opening any doors you don't > really need (or worse, didn't even intend to open). > > Another matter is the question of whether it might be easier to > produce a vulnerability when providing some function in the form of a > web service as opposed to another technique. One could argue in this > direction, e.g. because of creating new attack vectors such as XML > injection, or helping the attacker by providing the WSDL. But again, > this does not make web services incompatible with the principle of > minimal attack surface per se. > > Kind regards, > Holger Peine > > -- > Dr. Holger Peine, Security and Safety > Fraunhofer IESE, Fraunhofer-Platz 1, 67663 Kaiserslautern, Germany > Phone +49-631-6800-2134, Fax -1899 (shared) > PGP key via http://pgp.mit.edu ; fingerprint is 1BFA 30CB E3ED BA99 E7AE > 2BBB C126 A592 48EA F9F8 > > ___ > 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 > ___ 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] Google Auditing
Hi guys! A few days ago, following the announcements by Dan from Websense and then HD, I wrote a post covering what they have done and what the future may gold for Google hacking for security purposes. http://blogs.securiteam.com/index.php/archives/513 Today a guy posted a blog on using the filetype: feature to find coding errors: http://www.cipher.org.uk/index.php?p=projects/bugle.project Gadi. ___ 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
Re: [SC-L] "Bumper sticker" definition of secure software
On Mon, 17 Jul 2006, Rajeev Gopalakrishna wrote: > Reliability is concerned only with accidental failures while security has > to consider malicious attacks as well. The difference is in the intent of > the software user: benign or malicious. > > And for a bumper sticker, here is one for the pessimists: > > "Secure Software is a Myth" > > and another version for the skeptics: > > "Is Secure Software a Myth?" > > :) Again, this would speak only to a very small percentage of the population. You me, maybe 10K people around the world if we are generous. > > -rajeev > > > On Mon, 17 Jul 2006, Peter G. Neumann wrote: > > > You suggest: > > > > Secure software is software that remains dependable despite efforts to > > compromise its dependability. > > > > You need a bigger-picture view that encompasses trustworthiness > > and assurance. > > > > "Dependable systems are systems that remain dependable despite > > would-be compromises to their dependability." > > > > "Trustworthy systems are systems that are worthy of being trusted > > to satisfy their requirements (for security, reliability, survivability, > > safety, or whatever)." > > > > Security is generally too narrow by itself, because a system that is > > not reliable is not likely to be secure, especially when in > > unreliability mode! > > > > The principle of Keep It Simple is inherently unworkable with respect to > > security. Security is inherently complex. Trustworthiness is broader and > > even more complex. But if you don't think about trustworthiness more > > broadly, what you get is not likely to be very secure. > > > > Forget the bumper sticker approach. > > > > ___ > > 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 > > > ___ > 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 > ___ 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
Re: [SC-L] "Bumper sticker" definition of secure software
On Mon, 17 Jul 2006, Peter G. Neumann wrote: > Forget the bumper sticker approach. Hey Peter. :) Well, one should forget the bumper-sticker approach if all us broing dry guys keep try to explain to people how math works. Instead, teling them: 1+1=? Didn't learn math, eh? Is bumper-sticker worthy, if pointless as an example. In other words: "I read your email! When have you last audited your code?" ___ 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
Re: [SC-L] "Bumper sticker" definition of secure software
On Mon, 17 Jul 2006, Goertzel Karen wrote: > Another possibility: > > Secure software can't be subverted. We Read Your Email Your Program == Swiss Cheese > > -- > Karen Mercedes Goertzel, CISSP > Booz Allen Hamilton > 703.902.6981 > [EMAIL PROTECTED] > > ___ > 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 > ___ 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
Re: [SC-L] "Bumper sticker" definition of secure software
On Sun, 16 Jul 2006, mikeiscool wrote: > On 7/16/06, ljknews <[EMAIL PROTECTED]> wrote: > > At 3:27 PM -0400 7/15/06, Goertzel Karen wrote: > > > Content-class: urn:content-classes:message > > > Content-Type: multipart/alternative; > > > boundary="_=_NextPart_001_01C6A844.D6A28B6B" > > > > > > I've been struggling for a while to synthesise a definition of secure > > >software that is short and sweet, yet accurate and comprehensive. Here's > > >what I've come up with: > > > > > > Secure software is software that remains dependable despite efforts to > > >compromise its dependability. > > > > > > Agree? Disagree? > > > > I disagree about that being bumper-sticker size, and I think we really > > need bumper stickers. > > a better bumper sticker would be something like: > > "secure software is what i write. call me now to find out how!" "I read your email" jinx.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
Re: [SC-L] ddj: beyond the badnessometer
On Fri, 14 Jul 2006, Daniele Muscetta wrote: > On 7/13/06, Gary McGraw <[EMAIL PROTECTED]> wrote: > > > > 3) never use the results of a pen test as a "punch list" to attain > > security > > > > > You are right, but very sadly, that's how it gets used by a lot of > companies > "hey, the pen testers found problem 1, 2, 3 - we fix those, we are fine". No > way. But still I've seen this done in a lot of places Gary is correct on many issues, except for one: pen-testing is NOT black-box testing. Black-box testing is comparable to White-box testing in parameters of quantification. How the client deals with the results is unrelated to the type of results. It's directly linked to why they ordered the test and how they treat security. Gadi. > > Best, > > Daniele > ___ 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
Re: [SC-L] ddj: beyond the badnessometer
On Thu, 13 Jul 2006, Gary McGraw wrote: > Hi all, > > Is penetration testing good or bad? > > http://ddj.com/dept/security/18951 It's great, but "penetration testing" of the network assesment types is useless as it takes a picture of what the network look slike TODAY, while tomorrow it's a different network with different vulnerabilities. Automating the process is the way to go. As to software testing, it considerably depends on what you use. If you test with SATAN-comparable tools, well, you won't get far. > > gem > > company www.cigital.com > podcast www.cigital.com/silverbullet > book www.swsec.com > > > > This electronic message transmission contains information that may be > confidential or privileged. The information contained herein is intended > solely for the recipient and use by any other party is not authorized. If > you are not the intended recipient (or otherwise authorized to receive this > message by the intended recipient), any disclosure, copying, distribution or > use of the contents of the information is prohibited. If you have received > this electronic message transmission in error, please contact the sender by > reply email and delete all copies of this message. Cigital, Inc. accepts no > responsibility for any loss or damage resulting directly or indirectly from > the use of this email or its contents. > Thank You. > > > ___ > 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 > ___ 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] "Baking Security In" - Microsoft dev security training
http://softwaredev.itbusinessnet.com/articles/viewarticle.jsp?id=47176 Gadi. ___ 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
Re: [SC-L] HNS - Biggest X Window security hole since 2000
On Thu, 4 May 2006, Kenneth R. van Wyk wrote: > Stories about this (below) X bug and the DHS-sponsored project that found it > have been floating around the net all week. This story caught my eye, > though: > > http://www.net-security.org/secworld.php?id=3994 > > The author claims, "This flaw, caused by something as seemingly harmless as a > missing closing parenthesis, allowed local users to execute code with root > privileges, giving them the ability to overwrite system files or initiate > denial of service attacks." > > So, it sounds like a single byte change in the entire X src tree could fix a > bug that could give an attacker complete control of a system. Lovely... Hmm, I think this was fixed in earlier X versions. Gadi. > > Cheers, > > Ken van Wyk > -- > KRvW Associates, LLC > http://www.KRvW.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
Re: [Owasp-dotnet] Re: [SC-L] Is there any Security problem in Ajax technology?
George Capehart wrote: Yvan Boily wrote: Hi George, I think a much more eloquent form of what you are saying is that validation must be performed each time data crosses a security boundary. Hello Yvan, I absolutely agree. Wish I'd said it myself . . . :) In other words, it's just Javascript. Do your coding securely. I don't like the big buzz. This is nothing new. The challenge is in helping people to understand what a security boundary is. Errrmm. Into understatement these days, eh? :) I wish I had a good Yoda quote right now, but all I can come up with is Terry Goodkind, which I feel very ashamed of. Gadi. -- http://blogs.securiteam.com/ "Out of the box is where I live". -- Cara "Starbuck" Thrace, Battlestar Galactica. ___ 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
Re: [SC-L] Is there any Security problem in Ajax technology?
George Capehart wrote: Dinis Cruz wrote: I personally think that AJAX has the potential to create very insecure applications because it pushes the data validation and authorization layers back to the client (i.e. the browser) "AJAX brings 'Back the Rich Client' and all its security problems" Kentaro, on your AJAX application you must follow the rule-of-thumb of not trusting any data supplied by your own Client-Side-AJAX functions, and authorize every request. In a nutshell: any data validation and authorization decisions/actions made at the Client-Side-AJAX functions are only there for usability, and have NO security value. I enthusiastically agree with the above. I'll take it further and suggest that, even then, the input from the Web should/must be examined and sanitized before use . . . /*still*/ need to check for SQL injection attacks, etc. IMNSHO, identification, authorization and validation should always be done by the part of the system that is at risk if the input is bad (in any of the connotations of bad) . . . Indeed, but I believe the main point he was trying to make was: >>In a nutshell: any data validation and authorization decisions/actions made at the Client-Side-AJAX functions are only there for usability, and have NO security value. Much like with regular Java. Nothing changed. The issue is to think like an attacker. Any client-side defense can be thrown aside, discarded. Client-side defenses however are often very useful for "usability", i.e., so that the user is not allowed to send in bad Characters, or he/she wouldn't know their request was stopped server-side. Gadi. -- http://blogs.securiteam.com/ "Out of the box is where I live". -- Cara "Starbuck" Thrace, Battlestar Galactica. ___ 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] static analysis you say?
Just last month Greta Yorsh, fresh from work in Microsoft Research over in the US lectured to us on something related in TAUSEC (http://www.cs.tau.ac.il/tausec - in Hebrew). - Title: Testing, Abstraction, Theorem Proving: Better Together. We present a method for static program analysis that leverages tests and concrete program executions. State abstractions generalizes the set of program states obtained from concrete executions. A theorem prover is then used for checking that the generalized set of concrete states covers all potential executions, and satisfies additional safety properties. Our method finds the same potential errors as the most-precise abstract interpreter for a given abstraction, and potentially more efficient. Additionally, it provides a new way to tune performance by alternating between concrete execution and theorem proving. - Anyone follow that? I didn't. VERY basically put, she showed a system that was developed over 5 years that abstracts static code such as of device drivers to a simple boolean program, and then follows the code to find errors. Later comparing these errors to a run on a tad less abstracted program to see if the error is really there. ^^^ That is probably the worst description you will ever hear of SLAM. She claims that with her research (not SLAM) she can prove mathematically a program is secure.. erm. She was a very impressive lecturer and almost convinced me, I really was impressed. Here are some links from her lecture (ignore the first line which is in Hebrew): http://www.cs.tau.ac.il/tausec/lectures/Greta_Yorsh_links.html Gadi. ___ 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] it's not a bug, it's a feature!
Okay, if we are so keen to make distinctions, how about this one? In the recent WMF 0day, it was indeed a feature. But it was a security vulnerability non-the-less. PR-ing it as a feature was indeed, PR. Cisco released a security advisory, advising that a default root password is a "vulnerability" rather than a built-in feature. :) It seems that people often enjoy making the distinction for putting the right spin on things. Myself, I like this quote: "Any sufficiently advanced bug is indistinguishable from a feature". A spin on Arthur C. Clarke's 3rd law. I learned just a few months ago (last year :) ) that it was coined 20 years ago by someone many of us know: Rich Kulawiec. What is your take on this, should this be a huge argument as well? :) Gadi. ___ 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] heap protection in glibc - some questions
A friend of mine grabbed my attention to this today. I sent this to
another list earlier and decided it may be more fitting here on Ken's list.
In version 2.3.4 of glibc...
if (__builtin_expect ((uintptr_t) p > (uintptr_t) -size, 0) ||
__builtin_expect ((uintptr_t) p & MALLOC_ALIGN_MASK, 0))
^^^ This line was added.
There is also a comment on it:
+ /* Little security check which won't hurt performance: the
+ allocator never wrapps around at the end of the address space.
+ Therefore we can exclude some size values which might appear
+ here by accident or by "design" from some intruder. */
+ if (__builtin_expect ((uintptr_t) p > (uintptr_t) -size, 0)
+ || __builtin_expect ((uintptr_t) p & MALLOC_ALIGN_MASK, 0))
+{
+ errstr = "free(): invalid pointer";
+errout:
+ malloc_printerr (check_action, errstr, mem);
+ return;
+}
It was mentioned on http://www.securityfocus.com/columnists/359.
Now, my questions if some of you can be so kind as to try and answer:
In your estimation, how many people actually heard about this (outside
the tight circle of secure coding maniacs)?
In your estimation, how many people actually go through the pain of
upgrading glibc?
This seems effective to me. In retrospect, how effective did it prove to
be over the past year, in your experience? Is it too early to tell?
Heard of this? http://www.cs.ucsb.edu/~wkr/projects/heap_protection/
What's your take on it, and how do you compare the two?
I'd appreciate your input if you have the time.
A friend of mine might also write on this, but I would like some more
opinions.
Thanks guys!
Gadi.
___
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
Re: [SC-L] ZDNet: Microsoft to hunt for new species of Windows bug
Steven M. Bellovin wrote: I like this line: "This kind of threat has not been anticipated before", from Microsoft. Mobile code hasn't been anticipated? C'mon! I think they meant 'features that allow you to execute code have not been seen as a security issue before. We have no idea where and how many such instances there are.' Reminds you of anything? ;) Gadi. ___ 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
Re: [SC-L] Intel turning to hardware for rootkit detection
http://www.eweek.com/article2/0,1895,1900533,00.asp Gee this sounds just like virus wars, using add-on products to make up for weakness in the operating system. A reliable operating system would not permit such modifications in the first place Whatever happened with Intel NX technology? Anyone followed up on that? "Rootkits" in this case seem to be *more* a good name for this tech than what rootkits actually are. Gadi. ___ 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] [Fwd: DJB's students release 44 *nix software vulnerability advisories]
[Ed. Cross-posted from Bugtraq... KRvW] Subject: DJB's students release 44 *nix software vulnerability advisories Date: Thu, 16 Dec 2004 01:47:12 -0800 Message-ID: <[EMAIL PROTECTED]> From: "Thor Larholm" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Widely deployed open source software is commonly believed to contain fewer security vulnerabilities than similar closed source software due to the possibility of unrestricted third party source code auditing. Predictably, most users of open source software do not invest a significant amount of time to audit the applications they use and now a class of 25 students has discovered 44 vulnerabilities during a CS course. This small group of students highlights how individuals outside the security industry without special security prerequisites can still manage to outperform the average Bugtraq poster in sheer quantity of discoveries. This adequately validates the typical estimate of between 5 and 15 errors in every thousand lines of code. D.J. Bernstein (http://cr.yp.to/djb.html) is lecturing a course this fall at the University of Illinois at Chicago called "MCS 494: Unix Security Holes" (http://cr.yp.to/2004-494.html). One of the requirements to pass the course was to find and exploit 10 previously undiscovered security holes in currently deployed Unix software. With a class of 25 students discovering 44 vulnerabilities most students now expect to fail the course (http://it.slashdot.org/article.pl?sid=04/12/15/2113202). The 44 security advisories have been published at http://tigger.uic.edu/~jlongs2/holes/ Ariel Berkman has discovered a remotely exploitable security hole in 2fax, a text-to-TIFF converter. [remote] [control] 2fax 3.04 expandtabs overflows s buffer http://tigger.uic.edu/~jlongs2/holes/2fax.txt Limin Wang has discovered two remotely exploitable security holes in abc2midi. [remote] [control] abc2midi 2004.12.04 event_text overflows msg buffer; event_specific overflows msg buffer http://tigger.uic.edu/~jlongs2/holes/abc2midi.txt Limin Wang has discovered a remotely exploitable security hole in abc2mtex. [remote] [control] abc2mtex 1.6.1 process_abc overflows key buffer http://tigger.uic.edu/~jlongs2/holes/abc2mtex.txt Limin Wang has discovered a remotely exploitable security hole in abcm2ps. [remote] [control] abcm2ps 3.7.20 put_words overflows str buffer http://tigger.uic.edu/~jlongs2/holes/abcm2ps.txt Yosef Klein has discovered a remotely exploitable security hole in abcpp. [remote] [control] abcpp 1.3.0 process_directive overflows token buffer http://tigger.uic.edu/~jlongs2/holes/abcpp.txt Limin Wang has discovered two remotely exploitable security holes in abctab2ps. [remote] [control] abctab2ps 1.6.3 write_heading overflows t; trim_title overflows rest http://tigger.uic.edu/~jlongs2/holes/abctab2ps.txt Qiao Zhang has discovered two remotely exploitable security holes in asp2php. [remote] [control] asp2php 0.76.23 preparse() overflows token buffer; preparse() overflows temp buffer http://tigger.uic.edu/~jlongs2/holes/asp2php.txt James Longstreet and Tom Indelli have discovered a remotely exploitable security hole in bsb2ppm, a program to convert BSB image files to PPM image files. [remote] [control] bsb2ppm 0.0.6 overflows line buffer http://tigger.uic.edu/~jlongs2/holes/bsb2ppm.txt Ariel Berkman has discovered a locally exploitable security hole in ChangePassword, a YP/Samba/Squid password-changing tool. [local] [control] ChangePassword 0.8 runs setuid shell http://tigger.uic.edu/~jlongs2/holes/changepassword.txt Danny Lungstrom has discovered a remotely exploitable security hole in ChBg, a tool to change background pictures. [remote] [control] chbg 1.5 simplify_path overflows res buffer http://tigger.uic.edu/~jlongs2/holes/chbg.txt Ariel Berkman has discovered a remotely exploitable security hole in Convex 3D. [remote] [control] Convex 3D 0.8pre1 readObjectChunk overflows objectname buffer http://tigger.uic.edu/~jlongs2/holes/convex3d.txt Limin Wang has discovered a remotely exploitable security hole in csv2xml. [remote] [control] csv2xml 0.5.1 get_field_headers overflows token http://tigger.uic.edu/~jlongs2/holes/csv2xml.txt Ariel Berkman has discovered a remotely exploitable security hole in CUPS. [remote] [control] CUPS 1.1.22 hpgltops ParseCommand overflows buf http://tigger.uic.edu/~jlongs2/holes/cups.txt Bartlomiej Sieka has discovered several security problems in how lppasswd, version 1.1.22 (current), edits /usr/local/etc/cups/passwd. [local] [kill] CUPS 1.1.22 lppasswd ignores write errors, etc. http://tigger.uic.edu/~jlongs2/holes/cups2.txt Ariel Berkman has discovered a remotely exploitable security hole in dxfscope, a viewer for DXF drawings. [remote] [control] dxfscope 0.2 overflows ent_name buffer http://tigger.uic.edu/~jlongs2/holes/dxfscope.txt Ariel Berkman has discovered a remotely exploitable security hole in the elm/bolthole filter program. [remote] [control] elm/bolthole filter 2.6.1 save_embedded_ad
Re: [SC-L] Secured Coding
I truly believe this as no matter how secured we make our programs there will always be someone to figure how to break it. So many people replied to this, I will too. It is not about if someone could or might hack - with enough resources, they would. Even if it is by physically breaking in and replacing your software with their own. Point is not if someone can potentially break your software. It is about making it as difficult as possible for them to do so until it might even become "not worth it". Gadi.
