Re: [SC-L] Compilers
On 12/22/06, Gary McGraw <[EMAIL PROTECTED]> wrote: > I have a better idead. Stop using C++. Jeeze. Even better then that; stop programming insecurely. > gem *rolleyes* -- mic ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php 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] Could I use Java or c#? [was: Re: re-writing college books]
On 11/14/06, Crispin Cowan <[EMAIL PROTECTED]> wrote: > mikeiscool wrote: > > On 11/14/06, Leichter, Jerry <[EMAIL PROTECTED]> wrote: > > > >> The joke we used to make was: The promise of Java was "Write once, > >> run everywhere". What we found was "Write once, debug everywhere". > >> Then came the Swing patches, which would cause old bugs to re-appear, > >> or suddenly make old workaround cause problems. So the real message > >> of Java is "Write once, debug everywhere - forever". > >> > >> Now, I'm exagerating for effect. There are Java programs even quite > >> substantial Java programs, that run on multiple platforms with no > >> problems and no special porting efforts. (Hell, there are C programs > >> with the same property!) But there are also Java programs that > >> cause no end of porting grief. It's certainly much more common to > >> see porting problems with C than with Java, but don't kid yourself: > >> Writing in Java doesn't guarantee you that there will be no platform > >> issues. > >> > > True, but that doesn't mean runtime portability isn't a good thing to aim > > for. > > > It means that compromising performance to obtain runtime portability > that does not actually exist is a poor bargain. Runtime portability _does_ exist and the perfomance argument is old and outdated now, there's the hotspot compiler that can beat the lazy programmer (and aren't we all lazy?) and, although it's not java, you may note Raymond Chens' optimisation challenge[1] with C# and C++ and the results and discussion resulting. And of course there are other reasons aside from just the runtime portability to use Java; it's rich API, and so on. -- mic [1] http://blogs.msdn.com/ricom/archive/2005/05/10/416151.aspx ___ 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] Could I use Java or c#? [was: Re: re-writing college books]
On 11/14/06, Leichter, Jerry <[EMAIL PROTECTED]> wrote: > | > >> If there is some construct that NEEDS to be interpreted to gain > | > >> something, it can be justified on that basis. Using interpretive > | > >> runtimes just to link languages, or just to achieve portability > | > >> when source code portability runs pretty well thanks, seems > | > >> wasteful to me. > | > > > | > > You think source code portability is good enough such that runtime > | > > portability isn't really needed? > | > > | > Anything beyond source code portability tempts the customer into use > | > on a platform where the developer has not tested. > | > | But it has been tested, because if it runs on that jvm it has been > | tested for that JVM. a JVM version x on linux is the same as a JVM > | version x on windows. That's the point. Now maybe they try running it > | with a version x - 5 JVM, well fine, it may not work, but the response > | would be: "duh". > That would be nice, wouldn't it? > > Unfortunately, painful experience says it's not so. At least not for > applications with non-trivial graphics components, in particular. > > The joke we used to make was: The promise of Java was "Write once, > run everywhere". What we found was "Write once, debug everywhere". > Then came the Swing patches, which would cause old bugs to re-appear, > or suddenly make old workaround cause problems. So the real message > of Java is "Write once, debug everywhere - forever". > > Now, I'm exagerating for effect. There are Java programs even quite > substantial Java programs, that run on multiple platforms with no > problems and no special porting efforts. (Hell, there are C programs > with the same property!) But there are also Java programs that > cause no end of porting grief. It's certainly much more common to > see porting problems with C than with Java, but don't kid yourself: > Writing in Java doesn't guarantee you that there will be no platform > issues. True, but that doesn't mean runtime portability isn't a good thing to aim for. -- mic ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] Could I use Java or c#? [was: Re: re-writing college books]
On 11/14/06, ljknews <[EMAIL PROTECTED]> wrote: > At 10:31 PM +1100 11/13/06, mikeiscool wrote: > > On 11/13/06, Glenn and Mary Everhart <[EMAIL PROTECTED]> wrote: > > >> If there is some construct that NEEDS to be interpreted to gain something, > >> it > >> can be justified on that basis. Using interpretive runtimes just to link > >> languages, or just to achieve portability when source code portability runs > >> pretty well thanks, seems wasteful to me. > > > > You think source code portability is good enough such that runtime > > portability isn't really needed? > > Anything beyond source code portability tempts the customer into use on > a platform where the developer has not tested. But it has been tested, because if it runs on that jvm it has been tested for that JVM. a JVM version x on linux is the same as a JVM version x on windows. That's the point. Now maybe they try running it with a version x - 5 JVM, well fine, it may not work, but the response would be: "duh". > -- > Larry Kilgallen -- mic ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] Could I use Java or c#? [was: Re: re-writing college books]
On 11/13/06, Glenn and Mary Everhart <[EMAIL PROTECTED]> wrote: > Crispin Cowan wrote: > > Al Eridani wrote: > >> On 11/9/06, Crispin Cowan <[EMAIL PROTECTED]> wrote: > >> > >>> Prior to Java, resorting to compiling to byte code (e.g. P-code back in > >>> the Pascal days) was considered a lame kludge because the language > >>> developers couldn't be bothered to write a real compiler. > >>> > >> "Post-Java, resorting to compiling to machine code is considered a lame > >> kludge because the language developers cannot be bothered to write a > >> real optimizer." > >> > > I don't see what a bytecode intermediate stage has to do with "real > > optimizer". Very sophisticated optimizers have existed for native code > > generators for a very long time. > > > > Bytecode interpreter performance blows goats, so I'm going to assume you > > are referring to JIT. The first order effect of JIT is slow startup > > time, but that's not an advantage either. So you must be claiming that > > dynamic profiling (using runtime behavior to optimize code) is a major > > advantage. It had better be, because the time constraints of doing your > > optimization at JIT time restrict the amount of optimization you can do > > vs. with a native code generator that gets to run off-line for as long > > as it needs to. > > > > But yes, dynamic profiling can be an advantage. However, its use is not > > restricted to bytecode systems. VMware, the Transmeta CPU, and DEC's > > FX86 (virtual machine emulation to run x86 code on Alpha CPUs) use > > dynamic translation to optimize performance. It works, in that those > > systems all do gain performance from dynamic profiling, but note also > > the reputation that they all have for speed: poor. > > > > And then there's "write once, run anywhere." Yeah ... right. I've run > > Java applets, and Javascript applets, and the latter are vastly superior > > for performance, and worse, all too often the Java applets are not "run > > anywhere", they only run on very specific JVM implementations. > > > > There's the nice property that bytecode can be type safe. I really like > > that. But the bytecode checker is slow; do people really run it > > habitually? More important; is type safety a valuable property for > > *untrusted code* that you are going to have to sandbox anyway? > > > > So I give up; what is it that's so great about bytecode? It looks a > > *lot* like the Emperor is not wearing clothes to me. > > > > Crispin > > > Considering that on VMS, due to the use everywhere of a single calling > standard and a linker that can understand things, you can link any language > with any other language and get things to run. A single app with some pieces > in Fortran, C, Pascal, BASIC, and assembly language, all in one program, is > perfectly feasible. I have worked with such. Everything's compiled, everything > compiles to optimised machine code, and there is no interpreter needed. > > So why does anyone consider that multilingual development requires some kind > of interpretive runtime? The old P-system was current a LONG time ago now, > always did have speed problems (and took down some pretty decent apps with > that > ship in its day because they couldn't run as fast as native code ones). > > If there is some construct that NEEDS to be interpreted to gain something, it > can be justified on that basis. Using interpretive runtimes just to link > languages, or just to achieve portability when source code portability runs > pretty well thanks, seems wasteful to me. You think source code portability is good enough such that runtime portability isn't really needed? > Anybody know why .net uses a runtime of the sort it does? Because .net is microsofts clone of Java, so they copied everything. > Glenn Everhart -- mic ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] Could I use Java or c#? [was: Re: re-writing college books]
> And then there's "write once, run anywhere." Yeah ... right. I've run > Java applets, and Javascript applets, and the latter are vastly superior > for performance, and worse, all too often the Java applets are not "run > anywhere", they only run on very specific JVM implementations. You really can't judge java based on java applets; they are a really poor front, for reasons I assume you are aware. > There's the nice property that bytecode can be type safe. I really like > that. But the bytecode checker is slow; do people really run it > habitually? More important; is type safety a valuable property for > *untrusted code* that you are going to have to sandbox anyway? I believe major application servers run with -verify, which is appropriate and useful for them. > So I give up; what is it that's so great about bytecode? It looks a > *lot* like the Emperor is not wearing clothes to me. I think you just want to see him that way ;) > Crispin -- mic ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] Could I use Java or c#? [was: Re: re-writing college books]
On 11/9/06, SZALAY Attila <[EMAIL PROTECTED]> wrote: > Hi All, > > On Thu, 2006-11-09 at 10:20 +1100, mikeiscool wrote: > > > > You can definately get appropriate information via the stack trace > > with java's exception handling. It's strange to see you say debugging > > is _eaiser_ in c, typically people find it far easier in a managed > > language :) > > People are different. :)) > > I personally want to know what happens and I don't believe anything waht > I can't see. In C I can see the assembly code what (I hope) is a > deterministic thing. An interpreter is to big (to me) to think about it > as a deterministic thing. And yes, with ``normal'' bugs a managed > language could give me more possibility to find the place of the > problem. But I want to hope, that we don't commit normal bugs. :) So basically you are expecting the only thing to go wrong on your program is to be bugs in the VM? Be it java or c#? I find that really strange. Sure, there have been bugs in the JVM/C# VM but just the same there have been bugs in windows that will affect your c programs. I really don't see that being a feasible/likely enough scenario to not use one of these languages. > And with mysterious bugs, when you cannot reproduce it in a test system, > just the costumer some hundred miles away, I think that the stability of > the compiled code (and the core file what may created) is give more more > chance to find the right place. Right exactly, and the fact that you have a stable VM instead of a strange-patched-level of windows/linux os gives you a stable platform. -- mic ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] Could I use Java or c#? [was: Re: re-writing college books]
On 11/8/06, SZALAY Attila <[EMAIL PROTECTED]> wrote: > Hi All! > > On Mon, 2006-11-06 at 23:23 +1100, mikeiscool wrote: > > > > Hold the phone ... What debugging problems? What _specific_ speed > > issues? I'd be really surprised if your project couldn't be resolved > > with java; what specific problems are you facing? What tests have you > > run/consider to show that java's supposed "speed issues" will give you > > trouble? If it's just xml processing I'd say efficient data structures > > are what you care about, so java can help you there. > > 1. Debug > > When the program do something nasty or unwanted thing then in C I could > do a lot of thing to find what happened. > > For example I could make the program dropping a core and analyze it at > home. This needed because the program used some places where I cannot go > into. And there were bugs in program which is definitely a race > condition what is hard to reproduce. So it's not enough to write the > steps to reproduce the bug. > > And I'm not sure that I can get the complete state of the program (and > just the program) so I can detect where is the problem, even when the > problem is in the compiler. I think it's more harder in java language. You can definately get appropriate information via the stack trace with java's exception handling. It's strange to see you say debugging is _eaiser_ in c, typically people find it far easier in a managed language :) > 2. Speed > > Yes, it's maybe an outdated information but for example if there are a > java plugin in my web browser (not javascript, java, for example the > terminal plugin in some management page of AMD64 servers) or the > ``famous'' Hungarian social web page iWIW, which was programmed in JAVA > and was slow like Hell. That's a java applet; please don't judge Java the language based on applets; they are a really bad representation. Serverside java will be very effective and useful; what sort of client are you writing? Is it a website or a desktop app? Even if it's a desktop app, perhaps look to azureus to see a good, well running app written in java for the desktop. There are others. -- mic ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] Could I use Java or c#? [was: Re: re-writing college books]
On 11/6/06, SZALAY Attila <[EMAIL PROTECTED]> wrote: > Hi All! > > I read this thread and I little be afraid. I'm just ahead of a complete > rewriting of my program. The previous code was written in pure C (with > an OOP looks-like somewhere). > > This program should run on Linux, freebsd and windows platform. This > program is a GUI, so it has a graphical interface too but do a lot of > computing and xml handling. > > I know C the most, so C++ is the least step I have to do. But I'm > uncertain now that this is enough. When I have looked around for OO > alternatives the C# was dropped, because I couldn't find a > cross-platform graphical tools and Java was dropped because it's speed > and the possibilities of debugging problems. Hold the phone ... What debugging problems? What _specific_ speed issues? I'd be really surprised if your project couldn't be resolved with java; what specific problems are you facing? What tests have you run/consider to show that java's supposed "speed issues" will give you trouble? If it's just xml processing I'd say efficient data structures are what you care about, so java can help you there. > Is there any other alternatives or I left something or the C++ is the > only alternative for me? Certainly not. If all else fails you can write memory-intensive stuff in a dll and import it into one java or c#. It'll still be some lower-level coding (in c++ or c or asm) but at least it'll be isolated. You'll need to explain your program more ... -- mic ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] re-writing college books [was: Re: A banner year for software bugs | Tech News on ZDNet]
On 11/5/06, David Crocker <[EMAIL PROTECTED]> wrote: > mikeiscool wrote: > > >> > Don't go there, sister. Come up with some reasonable tests before making a > statement like that. "Assembly code can be as much as a million times faster > then the run time of a C++ version of the same algorithm." Bit useless, isn't > it? > << > > I would not have made the statement I did had the tests not been done and > provided very clear results. I am not at liberty to go into details of the > tests > I have been involved with, however if you Google for e.g. "C++ C# > performance", > you will see that other people are getting similar results. Right, so again your statement is useless without numbers and tests we can perform ourselves. You made the statement, so you either have to prove it or let it slide. -- mic ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] re-writing college books [was: Re: A banner year for software bugs | Tech News on ZDNet]
On 10/28/06, David Crocker <[EMAIL PROTECTED]> wrote: > Crispin Cowan wrote: > > >> > For me, the enemy in the room is C++. It gives you the safety of C with the > performance of SmallTalk. There is no excuse at all to be writing anything in > C++ yet vastly too many applications are written in C++ anyway. Instead of > trying to coax developers to switch from C++ to something "weird" like SML, > lets > encourage them to switch to Java or C#, which are closer to their experience. > << > > Unfortunately, there are at least two situations in which C++ is a more > suitable > alternative to Java and C#: > > - Where performance is critical. Run time of C# code (using the faster .NET > 2.0 > runtime) can be as much as double the run time of a C++ version of the same > algorithm. Try telling a large company that it must double the size of its > compute farms so you can switch to a "better" programming language! Don't go there, sister. Come up with some reasonable tests before making a statement like that. "Assembly code can be as much as a million times faster then the run time of a C++ version of the same algorithm." Bit useless, isn't it? Lets not forget that writing faster/more optimised code in c++ will be more complex and hence allow room for more errors then letting the c#/java runtime optimiser do the dirty work for us. > However, I suspect that most security-critical programs do not fall into > either > of these categories, What? Cryptography rings a bell ... > so C# or Java would indeed be a better choice than C++ for > those programs. > > David Crocker, Escher Technologies Ltd. > Consultancy, contracting and tools for dependable software development > www.eschertech.com -- mic ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] re-writing college books [was: Re: A banner year for software bugs | Tech News on ZDNet]
On 10/13/06, Craig E. Ward <[EMAIL PROTECTED]> wrote: > At 10:03 AM -0400 10/12/06, ljknews wrote: > >At 9:20 AM -0400 10/12/06, Robert C. Seacord wrote: > > > >> I'm also teaching a course at CMU in the spring on Secure Coding in C > >> and C++. > > > >Is there participation on this list from the (hopefully larger number of) > >CMU instructors who are teaching people to use safer languages in the first > >place ? > >-- > >Larry Kilgallen > > > I don't think saying "use safer languages" is a good way to say it. > It would help conditions significantly if greater care were taken to > match the choice of programming language to the problem to be solved > or application to be created. If a language like C is most > appropriate, then use it, just be sure to take the extra steps needed > to develop it securely. > > The problem is so much the programming languages as it is the way > they are used. Well, programming languages can go a long way to helping solve the problem, and it can be reasonably grey as to where to use what. Should I use php or ror? or python? or c#? I'd say there is a very appropriate and open space for nice "secure" languages to live and develop. > Craig -- mic ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] Secure programming is NOT just good programming
On 10/13/06, David A. Wheeler <[EMAIL PROTECTED]> wrote:
> mikeiscool claimed:
> > Secure programming is good programming.
> > Most books teach good programming.
>
> I strongly disagree with you, on both counts.
As is your right :)
> At the least, those who say they practice good programming
> practices, and books that say they teach good programming
> practices, are GROSSLY INADEQUATE for developing secure programs.
Sure.
> First, "Secure programming is good programming":
> Most people and organizations who claim that they perform
> good programming practices do NOT perform practices
> necessary for security. You could argue that therefore they
> aren't really doing "good programming", but that doesn't
> help fix anything.
That's not an argument against it. I believe it will help, anyway, if
you can say to the public: "this program is written badly" instead of
"this program is written unsecurely". Almost everyone doesn't want to
hear the second version. If they ask why, well you can explain. But
keep it simple.
> And organizations STILL generally
> place features over security, and when there's a perceived
> conflict, security almost always loses... and they'll STILL
> say that they practice "good programming" practices (they just
> happen to correctly implement insecure programs).
You can design an insecure program that is coded well, and hence only
insecure in the ways you wish. You are mixing secure/good programming
with secure/good design.
> Here are some practices you should typically be doing
> if you're worried about security, and note that many are
> typically NOT considered "good programming"
> by the general community of software developers:
> * You need to identify your threats that you'll counter (as requirements)
> * Design so that the threats are countered, e.g., mutually
>suspicious processes, small trusted computer base (TCB), etc.
> * Choose programming languages where you're less likely to
>have security flaws, and where you can't (e.g., must use C/C++), use extra
>security scanning tools and warning flags to reduce the risk.
> * Train on the specific common SECURITY failures of that
>language, so you can avoid them. (E.G., gets() is verbotin.)
> * Have peer reviews of the code, so that others can help find
>problems/vulnerabilities.
> * Test specifically for security properties, and use fuzz testing
>rigged to test for them.
> Few of these are done, particularly the first two. I'll concede
> that many open source software projects do peer reviews, but you
> really want ALL of these practices.
Yep.
> Next, "Most books teach good programming." Pooey, though I wish they did.
Okay that was wishful thinking.
> I still find buffer overflows in examples inside books on C/C++.
> I know the first version of K&R used scanf("...%s..."..) without noting
> that you could NEVER use this on untrusted input; I think the
> second edition used gets() without commenting on its security problems.
> A typical PHP book is littered with examples that are XSS disasters.
Fair enough.
> The "Software Engineering Body of Knowledge" is supposed to
> summarize all you need to know to develop big projects.. yet
> it says essentially NOTHING about secure programming
> (it presumes that all programs are stand-alone, and never connect
> to an Internet or use data from an Internet - a ludicrous assumption).
> (P.S. I understand that it's being updated, hopefully it'll correct this.)
>
> I'd agree that "check your inputs" is a good programming
> practice, and is also critically important to secure programming.
> But it's not enough, and what people think of when you say
> "check your inputs" is VERY different when you talk to security-minded
> people vs. the general public.
Yep.
> One well-known book (I think it was "Joel on Software") has some
> nice suggestions, but strongly argues that you should accept
> data from anywhere and just run it (i.e., that you shouldn't
> treat data and code as something separate). It claimed that sandboxing
> is a waste of time, and not worthwhile, even when running code from
> arbitrary locations... just ask the user if it's okay or not
> (we know that users always say "yes"). When that author thinks
> "check your inputs", he's thinking "check the syntax" -
> not "prevent damage". This is NOT a matter of "didn't implement it
> right" - the program is working AS DESIGNED. These programs
> are SPECIALLY DESIGNED to be insecure. And this was strongly
> argued as a GOOD programming practice.
Which is clearly wrong.
> > People just don't care.
>
> There, unfortunately, we agree. Though there's hope for the future.
>
> --- David A. Wheeler
-- mic
___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] re-writing college books [was: Re: A banner year for software bugs | Tech News on ZDNet]
On 10/12/06, Gadi Evron <[EMAIL PROTECTED]> wrote: > 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? Secure programming is good programming. Most books teach good programming. People just don't care. > Gadi. -- mic ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] Google code search: good or bad?
good or bad, it's quite old. www.koders.com has been doing it for years. considering the source is available for anyone to download anyway, and investigate themselves, i don't see the big deal. the engines just let you search a whole bunch at once, and why would any one company/product care about that? if you want to target them, you do. if you just want to find a bug in any given open source product, then one of these may be slightly useful. if the main concern is that code can accidently get online, well that problem has been around forever and will never go away. better to expose it and have it dealt with, really. all in all, no big deal. jmho. -- mic On 10/12/06, Gary McGraw <[EMAIL PROTECTED]> wrote: > Hi all, > > I spoke to Dennis Fisher about the Google code searching stuff that's > been floating around on the list for a few weeks (since the original > Bugle posting). Here's the resulting article: > > http://searchsecurity.techtarget.com/originalContent/0,289142,sid14_gci1 > 222898,00.html > > BTW, I wrote about this idea in my own article on darkreading back in > August: > > http://www.darkreading.com/document.asp?doc_id=100643 > > What do you guys think about the capability? Is it good or is it bad? > > gem > > company www.cigital.com > podcast www.cigital.com/silverbullet > book www.swsec.com ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] Coding with errors in mind - a solution?
On 9/1/06, Pascal Meunier <[EMAIL PROTECTED]> wrote:
>
>
>
> On 8/30/06 3:46 PM, "Tim Hollebeek" <[EMAIL PROTECTED]> wrote:
>
> >
> > What you've proposed are exceptions. They do help (some) in separating
> > the normal logic from error handling, but:
> >
> > (1) they often leave the job "half done" which has its own risks.
> > writing exception safe code can be more of a nightmare than error
> > checking.
>
> I can't help noticing... In Ruby there's an "ensure" clause that allows you
> to bring closure to half-done operations. Perhaps your point is that some
> languages have poor exception support, just like some languages don't
> provide safe string handling functions?
His point, I think, is that if you wrap a series of statements in an
try/catch block, you might not roll back every statement you needed
to, or checked appropriate conditions.
For example:
try {
openFile();
getData();
writeToFile();
setSomeFlag()
moveFile();
deleteTempThings();
} catch(Exception e){
...
}
Now obviously that's a statement that could be written far better, but
the point is that with the lazy/bad/accidental-bug-producing
programmer it might be common.
> >
> > (2) in many languages, you can't retry or resume the faulting code.
> > Exceptions are really far less useful in this case.
>
> See above. (Yes, Ruby supports retrying).
>
> >
> > (3) you usually end up with some "generic" clean up code, which generally
> > hides more errors than it solves.
>
> I don't think that's fair. Yes, you can write poor exception handling code,
> but it's far easier to simply ignore or overlook errors or write poor error
> handling code to the point where the error is effectively ignored (or
> "hidden") or the cause of the error becomes unidentifiable. Exceptions
> allow me to reduce code duplication (and lower the chance of inconsistent
> treatment and bugs), simplify the code (which makes it easier to understand
> and therefore audit) as well as handle problems at an appropriate layer in
> the code.
Exceptions simplify the code? I don't think so. They also don't reduce
code duplication [per se] you need to add extra functions, etc, to do
that.
> I'm not saying that exceptions are always the best way to handle things, but
> they can be part of good programming practices.
They _can_ be, but often aren't.
> Pascal Meunier
-- mic
___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] Web Services vs. Minimizing Attack Surface
On 8/16/06, John Wilander <[EMAIL PROTECTED]> wrote: > Thanks for all the replies so far! I would just like to comment on > Holger Peine's and Mike Hines' viewpoints. > > [EMAIL PROTECTED] wrote: > > I don't see a conflict here: A web service (just as any > > network-accessible > > service, no matter whether programmed using sockets, Java RMI, SOAP or > > whatever) is _intended_ to provide some function to the outside world, > > so you have to open _some_ door into your system. The advice about > > minimizing the attack surface is about not opening any doors you don't > > really need (or worse, didn't even intend to open). > > As you say, any kind of system is _intended_ to provide some function. > But security bugs often hide in unintended, undocumented or unknown > functionality. By increasing the attack surface you also increase the > risk of adding unknown functions. > > Mike Hines commented on web services running everything through port 80 > (HTTP) as negating "... any value of firewalls and most likely intrusion > detection systems". Indeed, web services tunnel a lot of functionality > through port 80, effectively hiding it from many system monitoring > defense measures. The security will rely on validating SOAP envelopes > and prevention at the application/run-time system level. It seems to me > like a huge burden. A huge burden or a huge benefit? You can validate everything in one spot, and maybe even solve problems in one spot. Imagine if everything went into the same system; thereby suggesting that all attacks would be similar (i.e. all attacks against the soap parsers of various apps, or something). If it all goes in one hole, you can fix it once with your IDS, or whatever acronym you have installed. You seem to be saying that any given app i want to write, and have publically accessible, I should write to accept connections on another port, or find another channel to operate on (maybe through a website app dll calls, or something). But then, if we do that, we have to re-write everything each time. Doesn't make alot of sense ... > Regards, John -- mic ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] Forwarded: PHP encryption for the common man
On 7/26/06, Kenneth Van Wyk <[EMAIL PROTECTED]> wrote: > > FYI, I saw an interesting article today on IBM's web site detailing how to > (and how NOT to) use encryption within PHP code. Those interested can find > the article at: > > http://www-128.ibm.com/developerworks/library/os-php-encrypt/index.html?ca=drs- This doesn't seem like a _great_ article, for the 'common man', as it involves, at least in the last step, executing a binary with propsed input from the user (i.e. a username, or something) as command line parameters. It validates one (the 'msg' from the form), but not the others that may be adjusted to accept input as well. Not only is the binary ran, but it would imply that the script as executable permissions on at least that file, if not the entire directory, or even entire system. All of which are bad. It also recommends to use md5, which is totally broken as a secure hashing function and should not be used at all. > Cheers, > > Ken -- mic ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] "Bumper sticker" definition of secure software
On 7/25/06, Dana Epp <[EMAIL PROTECTED]> wrote: > But secure software is not a technology problem, Yes it is. > it's a business one. > Focused on people. This is part of the issue, not the whole issue. > If smartcards were so great, why isn't every single computer in the > world equipped with a reader? The answer isn't that smart cards aren't great, it's that it's not a practical possibility. Maybe oneday it will be. > There will always be technology safeguards > we can put in place to mitigate particular problems. But technology is > not a panacea here. *sigh* I never said it was. No one said it was. > It is no different than "network security professionals" that deploy > $30,000 firewalls to protect digital assets worth less than the computer > they are on. (I once saw a huge Checkpoint firewall protecting an MP3 > server. Talk about waste.) Those guys should be shot for ever making > that recommendation. As should secure software engineers who think they > can solve all problems with technology without considering all risks and > impacts to the business. All this is interesting but useless for this discussion. Nobody said you should try and solve all problems with technology without consider the impacts to the business. Please go back and read the original posts to find out what we were talking about before going off on a boring, totally unoriginal, rant, that everyone here is already intimately familiar with. > Regards, > Dana Epp -- mic ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] bumper sticker slogan for secure software
> Sorry, but it is a fact. Yes, you can have provably correct code. Cost > is approximately $20,000 per line of code. That is what the "procedures" > required for correct code cost. Oh, and they are kind of super-linear, > so one program of 200 lines costs more than 2 programs of 100 lines. Someone already pointed this out but your numbers here have no basis. Provide references or something, otherwise they are meaningless. > > This isn't as true and as wide spread as you make it sound. Consider, > > for example, "SQL Injection". Assuming I do not upgrade my database, > > and do not change my code and server (i.e. do not change my > > environment at all), then if I have prevented this attack initially > > nothing new will come up to suddenly make it work. > > Indeed, consider SQL injection attacks. They didn't exist 5 years ago, Prove it. > because no one had thought of them. Same with XSS bugs. Again prove it. I might say that they didn't exist at a given time because apps that were affected weren't widely deployed. Online BBS's are relatively new, and that, to my memory, was the first place for XSS bugs. > What Dana is trying to tell you is that some time in the next year or > so, someone is going to discover yet another of these major > vulnerability classes that no one has thought of before. At that point, > a lot of code that was thought to be reasonably secure suddenly is > vulnerable. Right, but if your environment is unchanged and you've looked at all angles, then you will not be affected. Note that I'm not saying it's easy, but .. > > Not true; you can call other libraries happily and with confidence if > > you handle the case of them going all kinds of wrong. > > This also is false. Consider the JPG bug that badly 0wned Microsoft > desktops a while back. It was a bug in an image processing library. You > try to view an image by processing it with the library, and the result > is that the attacker can execute arbitrary code in your process. That is > pretty difficult to defensively program against. Why? > Crispin -- mic ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] "Bumper sticker" definition of secure software
> As a result, really secure systems tend to require lots of user training > and are a hassle to use because they require permission all the time. No I disagree still. Consider a smart card. Far easier to use then the silly bank logins that are available these days. Far easier then even bothering to check if the address bar is yellow, due to FF, or some other useless addon. You just plug it in, and away you go, pretty much. And requiring user permission does not make a system harder to use (per se). It can be implemented well, and implemented badly. > Imagine if every door in your house was spring loaded and closed itself > after you went through. And locked itself. And you had to use a key to > open it each time. And each door had a different key. That would be > really secure, but it would also not be very convenient. We're talking computers here. Technology lets you automate things. > Crispin -- mic ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] bumper sticker slogan for secure software
On 7/21/06, Dana Epp <[EMAIL PROTECTED]> wrote: > > yeah. > > but none of this changes the fact that it IS possible to write > completely secure code. > > -- mic > > And it IS possible that a man will walk on Mars someday. But its not > practical or realistic in the society we live in today. I'm sorry mic, > but I have to disagree with you here. > > It is EXTREMELY difficult to have code be 100% correct if an application > has any level of real use or complexity. There will be security defects. Why? Why accept this as a fact? It is not a fact. If you put procedures in place and appropriately review and test you can be confident. > The weakest link here is the human factor, and people make mistakes. Yes they do. So help them to stop it by teaching and testing and reviewing. > More importantly, threats are constantly evolving and what you may > consider completely secure today may not be tomorrow when a new attack > vector is recognized that may attack your software. This isn't as true and as wide spread as you make it sound. Consider, for example, "SQL Injection". Assuming I do not upgrade my database, and do not change my code and server (i.e. do not change my environment at all), then if I have prevented this attack initially nothing new will come up to suddenly make it work. If the environment IS changed, however, then of course it's expected that the program should be reviewed and checked again. > And unless you wrote > every single line of code yourself without calling out to ANY libraries, > you cannot rely on the security of other libraries or components that > may NOT have the same engineering discipline that you may have on your > own code base. Not true; you can call other libraries happily and with confidence if you handle the case of them going all kinds of wrong. > Ross Anderson once said that secure software engineering is about > building systems to remain dependable in the face of malice, error, or > mischance. I think he has something there. If we build systems to > maintain confidentiality, integrity and availability, we have the > ability to fail gracefully in a manner to recover from unknown or > changing problems in our software without being detrimental to the user, > or their data. > > I don't think we should ever stop striving to reach secure coding > nirvana. But I also understand that in the real world we are still in > our infancy when it comes to secure software as a discipline, and we > still have much to learn before we will reach it. Yes, Much to learn. Like the fact that it _is_ reachable if you believe you can reach it. And, you know, study yoga and live in a cliff for a few years. > Regards, > Dana Epp > [Microsoft Security MVP] > http://silverstr.ufies.org/blog/ -- mic ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] "Bumper sticker" definition of secure software
On 7/21/06, Florian Weimer <[EMAIL PROTECTED]> wrote: > * Brian A. Shea: > > > My slogan: > > > > Unsecured Applications = Unsecured Business > > Which is completely acceptable if you and your business partners are > aware of the risk level at which your are running your company. > > Secure software costs more, requires more user training, and fails in > hard-to-understand patterns. If you really need it, you lose. Really secure software should require _less_ user training, not more. -- mic ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] bumper sticker slogan for secure software
On 7/20/06, Andrew van der Stock <[EMAIL PROTECTED]> wrote: > Actually, it is a myth. > > For every non-trivial system, there are business pressures on > resourcing, deadlines, and acceptable quality (pick any two). Once a > business has set their taste for risk, it makes no sense to spend say > $10m on security controls on a product and delay it for six months > which may only bring in $2m in revenue in total, or none at all if > the company runs out of money to bring it to market. > > At the moment, most companies neither accept or assign the risk, > enumerate the risk correctly, nor take adequate steps to eliminate as > much risk as possible. We need to improve all three aspects. Even in > a perfect world, there will still be bugs and security defects. Let's > make sure that the remaining ones are really hard to exploit, and > when the exploit happens, not much loss occurs. yeah. but none of this changes the fact that it IS possible to write completely secure code. > thanks, > Andrew -- mic ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] bumper sticker slogan for secure software
On 7/19/06, Dana Epp <[EMAIL PROTECTED]> wrote: > Or perhaps less arrogance in believing "it won't sink". > > Absolute security is a myth. no it isn't. pretending it is a 'myth' is an attempt by sloppy programmers and designers to explain away the reasons for their applications failing. > As is designing absolutely secure software. > It is a lofty goal, but one of an absolute that just isn't achievable as > threats change and new attack patterns are found. Designing secure > software is about attaining a level of balance around software > dependability weighed against mitigated risks against said software to > acceptable tolerance levels, while at the same time ensuring said > software accomplishes the original goal... to solve some problem for the > user. > > On my office door is a bumper sticker I made. It simply says: > > 0x5 > > 10 points to the first person to explain what that means. security 101? -- mic ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] "Bumper sticker" definition of secure software
On 7/18/06, Goertzel Karen <[EMAIL PROTECTED]> wrote: > Another possibility: > > Secure software can't be subverted. Again you are all missing that point that design faults are a major *major* problem. Cannot be "subvered"; well fine. But what if the main function of the app itself is wrong. It is not a secure program in this case. -- mic ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] "Bumper sticker" definition of secure software
On 7/17/06, Crispin Cowan <[EMAIL PROTECTED]> wrote: > mikeiscool wrote: > > On 7/17/06, Crispin Cowan <[EMAIL PROTECTED]> wrote: > >> > Goertzel Karen wrote: > >> > I've been struggling for a while to synthesise a definition of secure > >> > software that is short and sweet, yet accurate and comprehensive. > >> > >> My favorite is by Ivan Arce, CTO of Core Software, coming out of a > >> discussion between him and I on a mailing list about 5 years ago. > >> > >> Reliable software does what it is supposed to do. Secure software > >> does what > >> it is supposed to do, and nothing else. > > and what if it's "supposed" to take unsanitzed input and send it into > > a sql database using the administrators account? > > > > is that secure? > > "supposed to" goes to intent. I don't know. I think there is a difference between "this does what it's supposed to do" and "this has no design faults". That's all I was trying to highlight. The point remains though: trimming this down into a friendly little phrase is, IMCO, useless. > If it is a bug that allows this, then it > was not intentional. If it was intended, then (from this description) it > was likely a Trojan Horse, and it is secure from the perspective of the > attacker who put it there. > > IMHO, bumper sticker slogans are necessarily short and glib. There isn't > room to put in all the qualifications and caveats to make it a perfectly > precise statement. As such, mincing words over it is a futile exercise. > > Or you could just print a technical paper on a bumper sticker, in really > small font :) > > Crispin -- mic ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] "Bumper sticker" definition of secure software
On 7/17/06, Crispin Cowan <[EMAIL PROTECTED]> wrote: > > > Goertzel Karen wrote: > > > > > > I've been struggling for a while to synthesise a definition of secure > > software that is short and sweet, yet accurate and comprehensive. > > My favorite is by Ivan Arce, CTO of Core Software, coming out of a > discussion between him and I on a mailing list about 5 years ago. > > Reliable software does what it is supposed to do. Secure software does what > it is supposed to do, and nothing else. and what if it's "supposed" to take unsanitzed input and send it into a sql database using the administrators account? is that secure? > Crispin -- mic ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] "Bumper sticker" definition of secure software
On 7/16/06, ljknews <[EMAIL PROTECTED]> wrote: > At 3:27 PM -0400 7/15/06, Goertzel Karen wrote: > > Content-class: urn:content-classes:message > > Content-Type: multipart/alternative; > > boundary="_=_NextPart_001_01C6A844.D6A28B6B" > > > > I've been struggling for a while to synthesise a definition of secure > >software that is short and sweet, yet accurate and comprehensive. Here's > >what I've come up with: > > > > Secure software is software that remains dependable despite efforts to > >compromise its dependability. > > > > Agree? Disagree? > > I disagree about that being bumper-sticker size, and I think we really > need bumper stickers. a better bumper sticker would be something like: "secure software is what i write. call me now to find out how!" ... i don't see the point of a short phrase. it's obvious what secure software is. software that has no bugs and no design faults. -- mic ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
