[SC-L] Unreal IRCd backdoor

2010-06-14 Thread Gadi Evron

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

2009-03-22 Thread Gadi Evron
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 ?

2008-03-14 Thread Gadi Evron
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)

2007-03-27 Thread Gadi Evron
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

2007-03-26 Thread Gadi Evron
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

2007-03-13 Thread Gadi Evron
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

2007-03-12 Thread Gadi Evron
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

2007-01-02 Thread Gadi Evron
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!

2006-11-09 Thread Gadi Evron
[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...

2006-11-07 Thread Gadi Evron
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...

2006-11-07 Thread Gadi Evron
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...

2006-11-07 Thread Gadi Evron
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...

2006-11-06 Thread Gadi Evron
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...

2006-10-30 Thread Gadi Evron
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...

2006-10-29 Thread Gadi Evron
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]

2006-10-12 Thread Gadi Evron
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]

2006-10-11 Thread Gadi Evron
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

2006-10-08 Thread Gadi Evron
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

2006-10-05 Thread Gadi Evron
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

2006-08-15 Thread Gadi Evron
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

2006-07-20 Thread Gadi Evron
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

2006-07-18 Thread Gadi Evron
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

2006-07-17 Thread Gadi Evron
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

2006-07-14 Thread Gadi Evron
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

2006-07-13 Thread Gadi Evron
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

2006-07-07 Thread Gadi Evron
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

2006-05-04 Thread Gadi Evron
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?

2006-03-16 Thread Gadi Evron

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?

2006-02-09 Thread Gadi Evron
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

2006-01-10 Thread Gadi Evron

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

2005-12-13 Thread Gadi Evron

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]

2004-12-18 Thread Gadi Evron
[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