[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] 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 mbr...@sans.org 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. ___
[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. ___
[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. ___
[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=-5897236579900914407q=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 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] 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 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] 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 [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=enlr=q=file%3A.wsdl%24+transferbtnG=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
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, 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] 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
[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
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_address
