Slashdot Mirror
Secure Programming
viega writes "Matt Messier and I have just launched a secure programming web site. While this site does support our new book The Secure Programming Cookbook for C and C++ , it also serves as a thorough resource for developers. It has numerous links to articles and other topical resources, new recipes that demonstrate secure programming techniques a large glossary and the obligatory web log. We accept outside submissions, and will reward the best recipe submission each month-- O'Reilly will publish it on the O'Reilly Network web site and will give the author a free book. There's already a decent amount of new content, including recipes on avoiding malloc()/new-related integer overflows, watching out for security problems in API differences and issues when truncating data. There's also an RSS feed for the web log."
Once you have worked 50 hours a week in a corporate setting for 5 years as a developer (2 years) and a run-of-the-mill network/system/any-god-damn-thing-they-can-get-you -to administer(4 years, you will understand.
Lesson #1: All Java programs are automatically secure.
:)
See, that's why I keep coming to Slashdot. You learn something new every day.
You want the truthiness? You can't handle the truthiness!
It's a good idea to have resources that are committed to security. Although some will claim that languages such as Java or C# prevent security issues, this is simply not true - there are many avenues to building security weaknesses... and those that think they're safe merely by using a particular programming language are in for a nasty surprise.
Of course, a web site and a few books won't prevent security issues - but the more it gets the word out about good programming practices, the better!
---
Herb Chambers - where my nightmare came true!
If you RTFA, or even just GATFA (glance at) you'll notice that the book has info on:
Random numbers
Input validation
Cryptography (e.g. ssh)
Buffer overruns are just one kind of problem you need to deal with when writing secure code. There are also DOS attacks and information theft. Even with Java, it can be quite challenging to ensure that data is properly encrypted and authenticated, and you still need to worry about permissions in the file system.
And let's not even dredge up the standard "why can't you just rewrite 100s of 1000s of lines of working C++ code in Java?" inanity.
Might Java or C# have their own security issues, where if the right set of things occur bad things could happen?
I'd rather use a language which doesn't give a false sense of security, a language which everyone obviously (well, we hope they do, but, true, not always the case) knows you have to do checks and specify how much space you really have (and so forth).
The really is no excuse to use a language like Java or C# to do your checking when you can do it yourself. Except of course, laziness >:P
Yes, Java is more secure than C/C++.
No buffer overflows
No dereferencing of null pointers
No object creation failures (all "new"s succeed)
No direct access to memory location
C/C++ have none of these protections. So yes, Java is more secure than C/C++.
I won't given the color scheme.
Buffer overflows should not happen in the first place. In most languages, they are impossible. They happen because A) most code is written in C or C++, and B) everyone makes mistakes (even the finest open source developers overlook simple buffer overflows).
Microsoft is moving to languages with managed types. If they had been using managed types all along, the overwhelming majority of Microsoft security holes would have never happened. In a few years, Microsoft software will be more secure than anything Open Source has to offer.
Open Source developers, on the other hand, arrogantly believe that they are immune to mistakes. They somehow overlook the countless exploits discovered in their own code (more than 500 in Debian over the past 4 years).
It is time for open source to wake up and start using better tools and better practices.
The really is no excuse to use a language like Java or C# to do your checking when you can do it yourself.
That is the most ridiculous argument ever. It is tantamount to embracing only the most basic building blocks of anything and claiming that any automation or pre-made combination of those blocks as wrong.
No, it is you who is wrong. Why do you use a computer instead of an abacus? Why do you use paper when you could carve notes into stone? Things progress, things get better, and things that once were boilerplate (like manual safety checking) are taken care of so you don't have to do any of the boilerplate stuff anymore.
Embrace the better technology. Don't cling to the past or you will be left behind.
Or for a quick and free guide, you can download the secure programming faq from one of the oldest websites on the internet-
Securing Programming FAQ
--
Analytic & algebraic topology of locally Euclidean meterization of infinitely differentiable Riemmanian manifold
These degrees are handed out like toilet paper these days.
Let's teach future American programmers proper security before they graduate and start writing professional software.
There's no excuse for the fact that in order to write good, clean, secure code, our youngsters have to visit websites like secureprogramming.com in order to just get by.
What a disgrace.
Reply or e-mail; don't vaguely moderate. Ex-O'Reilly/MIT employee, now a full-time Google employee.
use a language that was specifically designed with security in mind
like say, Ada
oh yeah, let the negative moderation begin
because programmer can't stand being held by the hand
too big ego
It's called LISP.
(And before anyone says "... but you can't write a kernel in LISP!", there are several LISP Machines out there which beg to disagree with you.)
did anyone actualy ever use algol? when you look at it, Algol was just a development lab for features of modern programming.
I am the Alpha and the Omega-3
No buffer overflows
Without throwing an exception and crashing the program.
No dereferencing of null pointers
Without crashing the program (java.lang.NullPointerException).
No object creation failures (all "new"s succeed)
Without crashing the program -- usually as spectacuarly as a C program since an out-of-memory condition will make Bad Things happen with the VM or JIT as well.
Sounds like a great candidate for writing an OS kernel in. Microsoft are you listening?
Viega's site disses Schneier's book, which everyone else seems to regard as gospel. What's up with that? I like a juicy feud as much as the next guy.
IEEE Standards Associate, IEEE Information Assurance, IEEE Computer Society and IEEE Baseline Operating System Specification Working Group (BOSSWG) has initiated a call for definitions of a new operating systems intended to securely control nearly all aspect of the operating system (including root).
Kinda sounds like Common Criteria, doesn't it; hopefully better.
The Secure Programming Cookbook for C and C++, Chapter 1: Find an Alternative to C and C++.
Seriously!
That is the most ridiculous argument ever. It is tantamount to embracing only the most basic building blocks of anything and claiming that any automation or pre-made combination of those blocks as wrong.
I was partially joking. But really, more complex blocks are more likely to be flawed, and this seems especially true when it comes to computers. And the worse part is, you'll never be able to throw away the basic building blocks anyway. After all, what do you think compilers will always end up generating? Machine Code!
By hiding the details behind a curtain, I think it is more likely problems will just get ignored, because "oh, the language is so secure". I would like to avoid that.
Lesson #2: No matter how obvious it is that you're trying to be funny, someone will mistake your comment for totally serious and sincere (or, in this case, totally sincere in sarcasm). Which leads to...
Lesson #3: Don't try and be funny. You'll just end up having to explain it, and--as the Heisenberg Principle attests--an explained joke ceases to be funny.
Seeing how the parent didn't specify which security issues were fixed by switching from C/C++ to Java, and the website is devoted to "secure programming" without regard for language, the parent gives the impression that switching to Java automatically renders an application completely secure.
Despite Java's safer memory usage, an application is still open to a wide variety of attacks. Such grandiose security claims about managed languages are worthless (except for the schmucks trying to get a contract to rewrite a critical application in Java or C#).
See? See how not-funny you made me?
You want the truthiness? You can't handle the truthiness!
Without throwing an exception and crashing the program.
Which makes it unavailable for hacking. No program, no access.
Yes, a DoS will occur, but your site is safe.
Besides, a properly written Java app WILL have a try/catch block at some basic level to do a last ditch effort to intercept (and deal with) a normally fatal exception.
- - - - - - - - - - -
I am a programmer. I am paid to produce syntax not grammar. Deal with it.
It's more than just speed issues. Interpreted languages have better runtime checking and thus can avoid things like buffer overruns, yes. That's great for a lot of things, don't get me wrong. For backend programs, Java is an absolutely brilliant language, as it encourages some much better object-oriented design philosophies. Even Objective C handles some runtime checking far better than C or C++, though as it is a set of extensions to C it suffers from the same weaknesses in C code.
:) Last I checked, the original Java Virtual Machine was written in C...after all, you can't run Java bytecode without something to interpret it. Similarly, I bet you most Just-in-Time Java compiler/interpreters are also written in C or C++. Even the programs which take Java code and turn it into a binary executable likely are linking it against a library which was written in C or C++.
:)
/do/ solve some problems which traditional lower-level languages are more vulnerable too -- modern interpreted are not a panacea for all programming ills. They aren't suitable for all types of programming, and even for the ones they are well-suited for, they don't automatically solve all security issues.
;)
But what is the JVM written in? I guarantee you it isn't Java.
Similarly, at my old job, I had to write low-level drivers for PCI hardware we were developing. Did I get to write these drivers in Java or C#? Of course not... you can't write low-level hardware calls such as Windows VXD files in an interpreted language; it'd really kill the performance of a system.
Just for a moment try to imagine someone writing, say, a new video driver for the Linux kernel in Python, or rewriting XFree86 in Java.
Ow.
Moreover, while Java makes it a great deal harder to, say, create a remote root exploit through a buffer overrun, it does not automatically fix problems of, say, cryptographic strength. Creating an encryption algorithm for some vital data which can be easily broken is as much a security hole and a flaw as a buffer overrun.
So while you're correct in some places -- Java and Python and C# and other interpreted languages that can do more stringent runtime checking of things really
In general, the lower-level the language, the more easily you can mess it up; ASM is even easier to fry things in than C or C++. It becomes a tradeoff, with the lower-level languages giving you progressively greater efficiency and the ability to access things 'down on the metal', with higher level languages -- while slower and more abstracted -- able to shield you from more mistakes, and more portable between situations.
Each has their place. I wouldn't want to write a web-client that ran database queries in ASM, but Java works great. Conversely, I wouldn't want to write a driver for an AGP graphics card in Python, but ASM or C works pretty well right there.
--Rachel
You want the truthiness? You can't handle the truthiness!
This same argument is made by Paul Graham all the time when discussing Lisp. It still holds true.
High level languages allow you to do more with your programs because they provide means of doing repetitive things easily and allow the programmer to focus on the programming instead of worrying about the language.
People still use JOVIAL, which as far as I can gather is a version of Algol that has been modified to include threads. In fact, there is an official Air Force website at Jovial Lives!. To quote from the website:
"Some of the more notable weapon systems using JOVIAL include (but are not limited too) the Advanced Cruise Missile, B-52, B-1, and B-2 Bombers, C-130, C-141, and C-17 Transport Aircraft, F-15, F-16, F-18, and F-117 Fighter Aircraft, LANTIRN, U-2 Aircraft, E-3 AWACS Aircraft, Special Operations Forces, Navy AEGIS Cruisers, Army Multiple Launch Rocket System, Army Blackhawk Helicopters, F100, F117, F119 Jet Engines, and RL-10 Rocket Engines."
That's a pretty impressive list of platforms for a language that was developed in the early 1960's!
So, maybe newer is NOT better after all.
A.R. Nemmer
This isn't true whatsoever. Only the most glaring issues are fixed. Currently, we're working on a Java Secure Programming Cookbook, and we'll get around to C# after that.
We do a lot of code auditing, and find about 4-5 serious security problems per thousand lines of code of C and C++ code. In languages like Java, we still usually find 1 or 2 such problems.
Are these problems that you find inherent in the language itself (buffer overruns, etc) as in C/C++, or are they implementation problems that one would find in any bad implementation done in any language?
By hiding the details behind a curtain, I think it is more likely problems will just get ignored
So you, um, write software in machine code?
Higher level languages exist because it is tedious and error prone to need to code every last bit (pun intended) of instructon required by the CPU to do any work. The higher level the language, the more insulated you are from the machine code.
Assembler required you to know registers, C and C++ require you to free memory resouces. Java requires you to open/close files. SQL requires you to know table and column names. Each step up requires less and less knowledge of the underlying system. And each step up is safer overall.
But ANY language can be written so it is insecure and/or buggy.
We will reach a day when the Star Trek type of information retrieval and manipulation is done. We are not there yet.
- - - - - - - - - - -
I am a programmer. I am paid to produce syntax not grammar. Deal with it.
Fine, use Lisp, it is 100% secure as a consequence of its design and implementation, and you will understand why C/C++/C#/Java are not only crap (in every way imaginable) but also they are unnecessary crap. The problem with software is C and its derivatives.
www.cgisecurity.com/lib large library of documents
Secure java development
Secure XML
Secure Web Services
Sir, I have your other book "Building Secure Software", where you described the famous "CIA" security objectives as Confidentiality, Integrity and Authentication. AFAIK CIA has always been taught as Confidentiality, Integrity, and *Availability*. So what's up with A being Authentication?
"Now I'm just a lowly IT worker, managing web servers and crawling under desks"
Crawling under desks? I know admin'ing IIS servers is bad enough because of the security problems, but to have to blow your boss to keep your job?
Talk about getting fucked in both ends!
Agreed. Most of the companies I've been at of course hire college grads I mean who wouldn't, but most of the time it's those of us without degrees who've actually DTFW (done the fscking work) who end up making the big bucks even if it's only temporarily. This is not to say that a college grad isn't skilled hell most would probably clean the floor with my ass (well most compsec students with BA's and better). It's a matter of adapting to where you're at, while one may lack on say programming, they may make up for in networking. Not everyone can know it all (except of course moi... kidding you know...) But for the most part I would blame companies for jumping on the paper bandwagon. Just because someone has a degree doesn't mean that person is going to understand the actual business infrastructure of a company. They may understand the underlying protocols but that shit doesn't impress me when you have to run to a colo @ 3:00am and get shit started yesterday. Nope sorry bookworms your school lessons will not save you.
The fact is, most companies couldn't give half a shit about security on a day-to-day basis, and therefore don't really care if people fresh out of college have a clue about secure programming, or even security in general.
True to an extent. More and more companies are taking compsec more serious, and it helps when the gov, and news agencies go overboard with their 'hacker' stories. Take a look around Dice dot com, or the Security Focus job list, you will see the biggest surge in years.
MoFscker
So you, um, write software in machine code?
Higher level languages exist because it is tedious and error prone to need to code every last bit (pun intended) of instructon required by the CPU to do any work. The higher level the language, the more insulated you are from the machine code.
True, I like some insulation (it'd be difficult without it), but I like to avoid too much. In the very least, I think it's a good idea to know what's going on behind the magic curtain, and hiding what's going on to much could lead one to ignore what's going on completely.
C isn't always the best language, but it's the most versatile (at least I think so) without sacrificing too much. Hey, it's even somewhat portable (er...well...sometimes).
However, since I already own at least one of your books I'll check it out.
In the very least, I think it's a good idea to know what's going on behind the magic curtain...
Amen to that. I firmly believe that I am a better developer (not just coder) because at one time I DID write in machine code (it was a hardware computer course). I actually do know the major internals of a CPU, and how they react. Half-Adder anyone?
- - - - - - - - - - -
I am a programmer. I am paid to produce syntax not grammar. Deal with it.
Tune in to Bugtraq some time to see a never-ending stream of web-app vulnerabilities. Most of these applications are not written in C.
Moral of the story: stupid programmers will be stupid in whatever language you give them.
oh wait...
By the way, I can't believe nobody made that joke yet.
Quid festinatio swallonis est aetherfuga inonusti?
Africus aut Europaeus?
Also, note that many programming languages are implemented in C, and have had or might have security problems relating to that. I've seen such problems in several common scripting languages. It is like that there are plenty of other problems like that waiting to be found.
I bet Lisp could solve world hunger!
Lesson #3: Don't try and be funny. You'll just end up having to explain it, and--as the Heisenberg Principle attests--an explained joke ceases to be funny.
Hey, the Heisenberg Principle states that it is not possible to determine the position and velocity of a particle at the same time! That has nothing to do with jokes! This is a troll!
Moving to interepreted languages mean that any dodgy user-supplied input will be detected at runtime, and will most likely result in some sort of a traceback (but no exploitable overflow).
This however does not eliminate the remaining classes of vulnerabilities, relating to default configurations (username/passwords), poor encryption mechanisms, Denial of Service attacks (minimised due to most popular interpreted languages having their own garbage collection), and more.
We need more developers to be putting on their black-hats, and looking at their code and wondering "what if I tried this? Could I break this code?".
Man watching 6 MSCE's around a sun box, looks alot like the opening scene's of 2001:space odyssey...
1. Create your own malloc/free new/delete heap. This heap should always have blocks of 0's interspersed throughout and a 1K walled block of 0's at the end of the heap. Any programming errors may result in garbage, but it won't result in injected code vulnerabilities.
2. No direct DB access technology on your web service front ends. If your web UI code has SQL in it, you're doing something wrong. Your Web GUI should access an intermediate layer, instead. UI is notoriously easy to compromise, and the best way to make SQL injection attacks is to not have SQL directly beneath the button your users are playing with.
The problem is not the language, it's our style of programming.
The whole reason that security issues have proliferated is our stubborn insistence on allowing for variable input. If all input and systems had hard wired capacities, then, there could be no denial of service attacks as program behavior would be bounded.
Even C# and Java have DOS issues becuase of their unbounded nature. A program that reads an input stream and stuffs a link lists will be just as supsectible to denial of service attacks as any others.
Some of us remember gravitating over to C from the old Pascal and FORTRAN and BASIC because of C's penchant for creating dynamic data structures. AS I look back on that era, I wonder if we didn't make something of a mistake.
I wonder if we might borrow some of the practices from that ancient era, and use dynamic allocation as the exception, rather than rule. Programs should have fixed numbers of objects. Programs should have fixed input sizes and maximum capacities. String fields should always have a maximum, fixed, size.
I should note that if we do have less variable length allocations, then, we less likely need programming languages that make variable length easy. A more conservative, almost retro programming technique could make for faster, more secure programming.
This is my sig.
while(true)
...
//try again
{
try
{
}
catch()
{
}
}
bite my glorious golden ass.
The basic idea is that everything is reference counted and subscript checked, but by doing some static analysis and type enforcement, most of the overhead for that is eliminated at compile time.
About 95% of subscript checks can be optimized out without too much effort. An optimizing compiler that can hoist expressions out of loops and strength-reduce them can move most subscript checks out of inner loops. Reference counts require more language support, but they, too, can be optimized.
As for pointer arithmetic, the solution is to use iterators, which are checkable, instead of pointers, which are not. Then optimize out the checks, as with subscript checks.
I proposed that there be a way to designate C++ code as "strict", turning on the enforcement. Privileged programs should be 100% strict; others need not be.
This is unlikely to happen, but it is technically possible.
... is any programming job that can't be exported to India!
"Lord, grant that I may always be right, for Thou knowest that I am hard to turn" -- A Scots-Irish prayer
Been in the security game for 10 years...
From all these posts, it seems that all programmers don't have a clue about programming in a secure manner. I disagree, its just that times have changed.
Surely, a few years ago this was the case. But certainly not as bad as now. Most PHB worth their weight usually know the security buzz words associated with an implementation are. If they don't give support to the developers to create a secure solution, they arent just lacking in security skills - they are lacking in overall management skills and an understanding of IT. Security has to be part of the overall process when in development, PHB's must invest *training* for programmers and develop standards to follow.
Previous posters saying that it should be manditory for all post grads to have indepth security skills is down right short sighted. Security is a bottomless pit with many variables, a general subject can be taught. However, security can't stem strictly by programming practices. It is a collection of standards from all types, from the network, operating system to the application level. Not to mention the usual deal of people, process and technology.
I've lost count of how many pen tests I've completed where the application design was rock solid, however they had a bad password on their admin portal.
Nuff said....
no matter how good their secure coding is, they're no match for the ultimate overflow: the slashdot effect!
If you are going to (almost) shamelessly promote your own site on slashdot, please make sure your "secureprograming" servers are...
NOT SLASHDOTable!!!!!!
I think I have spotted a small error in your otherwise excellent site.
I checked out the HTML source and the problem seems to be in the spc.css file.
There are several references to the value #BD3D89 and on the monitors I have here that value appears as a bright pink colour.
Just thought I'd let you know.
Simple black on white:
Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator, mmessier@secureprogramming.com and inform them of the time the error occurred, and anything you might have done that may have caused the error.
More information about this error may be available in the server error log.
-----------------
Apache/1.3.28 Server at www.secureprogramming.com Port 80
-jpeg
Well, since it was slashdotted, I found the Google cache, the front page:
here.
Just in case the site gets slashdotted, here's a cut-n-paste of the home page. Whew, glad I was able to get in to get this:
Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator, mmessier@secureprogramming.com and inform them of the time the error occurred, and anything you might have done that may have caused the error.
More information about this error may be available in the server error log.
Apache/1.3.28 Server at www.secureprogramming.com Port 80
20+ years ago I used an operating system that was written in Pascal. There have been commercial operating systems written in FORTRAN, PL/I, LISP and other languages.
Mea navis aericumbens anguillis abundat
The only starving people here are the Lisp programmers.
President of America: I will give you thirt..thirt... thirt... thirt... thirty million dollars for sustainable food resources in third world countries.
Reporter: 30 30 30 30 million... 810 trillion dollars?
President of America, embaressed, not wanting to admit defeat: Undoubtly yes.
-Docvert converts MSWord to OpenDocument, clean HTML
Buffer overruns are one of the problems you don't need to deal with when writing secure code because modern languages (not C/C++) can detect that condition for you, leaving you to concentrate on the real bugs.
So much for "warding off". :p
Right now, the most interesting of these better languages looks to be Cyclone (from Cornell) which has some chance of success because it is based on C. Certainly(?), next genration versions of C and C++ ought to prevent such problems unless the programmer explicitly permits them.
Absolutely, I have predicted that the great slide of American Productivity (known observance where IT spending dramatically increased yet companies observed no dramatic improvements in productivity) from the mid-80s to the late 90s would be seen as a function of C (returning void).
Quoting Bjarne Stroustrup when some moron tried to flame him for C++'s perceived lack of security, "I assume that a sufficiently skilled [cracker] will be able to do anything not explicitly forbidden by the hardware." (Emphasis mine.)
So, the second rule is, recognize that most "levels of protection" and "access controls" in programming languages are there to help realize a clean design and facilitate debugging. NOT to enforce some kind of real-world security.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
- a program enforcing a division of data,
- ensuring a program doesn't let any bits slip through the cracks, and
- creating a system where people can do only the things they are allowed to do.
"Security" to me is (3). Security is a social construct. You can't have security until there is someone who's not allowed access to something.I see a lot of talk about cryptography, preventing buffer overflows, and so forth. But the combining of these technologies in the design of a real-world security application is seldom discussed. It's a hard messy problem.
I suspect if we had a better understanding of the social aspects of security, more secure technology would follow.
Just because I watched the movie the other night and can therefore quote entire reams from memory:
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
hundreds of thousands isn't too much effort is it?
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
This site needs some way of posting comments or feedback. For example, I have issues with at least two of the recipes listed so far. Secure programming sites and recipes are no use if they aren't subject to peer review.
i-name =twylite [http://public.xdi.org/=twylite], see idcommons.net
What about programming languages that define their own virtual hardware (VMs) ?
Freedom is the freedom to say 2+2=4, everything else follows...
Guys check the 9/15 th post
..why do you think MS switched to state machienes in MS .NET..its ecure, duh!
Not only does the author disspove his own conclusion..in fact switching to java does accidently make a program more secure
But other wrong assumptions abound..
Be very carefull of reading the book the author has written if its ful of the same assumptions..you might get burned..
Don't Tread on OpenSource
Wow, thanks, things like those sell away quickly, I better go get a payday loan and bid on that item as much as I can.
It amazes me that all people can think of when talking about "alternatives to C" is interpreted languages.
Folks, compilers for real languages have been available for ages. Dylan, Common Lisp, OCaml is probably the top of tools these days.
Lazy?
It's far easier to program in Java, but you never know what's happening in the interpreter.
At least with C/C++ you are talking directly to the machine, and it's your fault if it screws up.
What if you're really lazy, and rely on a JVM that you have no control over to provide your safety blanket?
Noone uses assembley any more (except for kudos purposes), but the closer you are to the hardware, the more care you have to take to make things right - interpreted languages make people lazy, and that must be a bad thing.
oh brave new world, that has such people in it!
University courses on programming do teach something about security, or good programming standards in general.
However, the student who starts working after college often finds himself in an environment without good work practices, standards and guidelines, tight deadlines, and disinterested co-workers. In that environment, his knowledge about programming practices will not be reinforced, it will be forgotten. The problem is not that he hasn't been taught properly, but if no-one is practicing or even interested in the standard of coding, is he going to bother?
Writing good software is something that's hard to teach anyway. Good programmers are made by experience, not by taking courses. However, junior programmers can learn how to produce quality code quickly... with your help. Training up junior staff is not something that you senior techs should do just if you feel like it... it should be part of your freakin' job description!. A seniour tech who does not pass on his knowledge is a dysfunctional employee.
You may want to check that you practice what you preach. Set a good example. Encourage your peers to do likewise.
- Teach: Do you see where a junior (or even senior) team member is slipping, and not applying proper practices? Chances are others have the same problem. Organise a short (1 hour) session and explain things. How to use the source control system. Where to find project documentation (you'd be surprised how often this is neglected). Take a piece of bad code, and explain why it is bad, and how to improve it (Don't haul out the poor guy who wrote it out in front, and remove his initials from any comments).
- Train: You got 2 junior C programmers assigned to your team? The best thing for them would be to receive a short course (give by you!) in Intermediate C programming techniques. This is knowledge straight from the horse's mouth, that they can apply immediately in their everyday work. Use the project as example, and they'll be brought up to speed on the important project aspects as a bonus. Besides giving a list of further reading at the end of the course, give them the actual books that you yourself have found to be beneficial to the subject.
- Coach: Take your time with the junior team members. Write code with them instead of correcting their mistakes after they have written it. Try pair programming with them. Personally I have found the time I spent with senior programmers (when I was the junior) to be the times when I learned most.
- Awareness: Never stop to instill the importance of good coding practices into your team members. Do not ever pass a bit of bad coding; make sure it is corrected. Got a tight deadline? Do not pass bad code anyway. As the team becomes better used to coding in a proper manner, you'll see less bad code and less bugs to boot, and you might end up saving time.
I've worked both in teams writing slipshod code, and teams producing tight code to rigid procedures, with a hard-ass technical manager making sure everything was up to standards. Guess which team was more fun to work in?
If construction was anything like programming, an incorrectly fitted lock would bring down the entire building...
Unfortunately, in a real world situation (as opposed to the dreams of someone walled in their own ivory tower), a program that crashes regularly is just short of useless. A program which malfunctions in the middle of writing data -- because half the logic got shortcircuited by a RuntimeException that cut straight through the last ditch "catch (Throwable all)" block -- is worse than useless.
For a geek, crashing early might be good coding practice. For a user, it's one e-commerce site they'll never visit again. (Yes, in a recent study, the main criticisms were stuff like the web site having a brain fart AFTER it swallowed the credit card number, leaving the user with no clue as to whether the order was processed or not.) Congrats, your site wasn't hacked, but the company is losing money hand over fist anyway.
Don't get me wrong, I'm not against Java, and I _do_ understand its advantages.
_But_ if using Java is your _only_ security, then you're doing it awfully wrong.
In Java, like in any other language, you _still_ have to do your own checks, and make some effort that the program will still work when confronted with malformed input. Especially when such input is not even a hacking attempt, but some hapless user typing "Jan 23, 74" instead of "23/01/1974" as you would like him to. Or he's included spaces in the credit card number (which causes Long.parseLong() to throw an exception.) Or whatever.
You do _not_ want the program to crash early and safe on the user, you want it to display a clear error message, and give the user plenty of clue as to how to correct the problem. And a chance to do so.
You also have to account for such user deviations as "what if he opens a link in a separate page, so now we have TWO pages sharing the same session id. And the user is doing different things in each." That's absolutely _deadly_ for brain-dead sites which store everything in the session. Just because Java's servlet interface makes it easy to store stuff in the session, doesn't mean it's also _safe_ to do so.
I've seen at least one e-commerce site which ended with products flagged "new user" and users flagged as "sold", because they relied on the session in the wrong way. Yes, noone took over their site, but the cost of that screw-up was very high nevertheless.
Briefly: again, just programming in Java doesn't automatically make your programs bullet-proof. There is no auto-magic substitute for good coding and design.
A polar bear is a cartesian bear after a coordinate transform.
> These security problems are fixed by switching to a modern language
Agreed...
> like Java or C#
These are *not* really modern languages... they are too much of procedural kludges to do OO, their runtimes are too big and they are too complex. They end up creating many problems.
If you want good languages, not just popular ones, go functional (Lisp, ML or their dialects) or pure OO like Smalltalk.
Leandro Guimarães Faria Corcete DUTRA
DA, DBA, SysAdmin, Data Modeller
GNU Project, Debian GNU/Lin
--
-- There are 10 kinds of people in the world, those who understand binary and those who don't.
Looks like I found the first site to visit in the morning in order to wake me up...jesus...is it safe to open my eyes yet?
To start, the parent comment should be modded back up. The parent poster isn't a troll; (s)he just has strong opinions.
Onto the post ...
Geez, how hard can this be? C and C++ are the only two major languages
on the market nowadays which allow array overflows, pointer dereferencing
into code, free creation of unsafe code, and other fun stupidities. As such,
they are easily the WORST LANGUAGES on the market for secure
programming.
This is a common programming fallacy. It's not the programming language that makes it easier to create a secure program; it's the programmer with a thorough understanding of security that makes the (infinitely approaching) secure program.
Sure, people will say oh, yeah, but you can be insecure in any
language. These people should have their CS degrees revoked.
They're right (and if you had your way, I'd have my piddly degree revoked in a few seconds :P)!
There are dozens of popular programs written in C/C++ in which security holes haven't been found, programs that are written carefully and thoroughly debugged by programmers that understand security. Programming languages like Python, Ruby, LISP, [... ad nauseum] make it easier to avoid common pitfalls (i.e. buffer overflows), but there are plenty of security holes that can be introduced into programs written in those languages.
Don't get me wrong. I'm a Python zealot, I like Ruby, and I think Modula-3 has (had?) the potential to be one of the best systems programming languages available (if not for the lack of tools associated with Modula-3). However, that doesn't change the fact that there are great C/C++ programmers out there that will write less buggy code in their lifetimes than many Python/Java/Ruby/[insert your favorite language of convenience] programmers that don't know the first thing about computer security.
I could apply your logic to language interpreters/compilers for some of the languages you mentioned (i.e. Java, Python, Ruby, etc.). Is the Python interpreter less secure than a Python program because the interpreter was written in C? If the interpreter is insecure, then what does that say about Python programs when they're being interpreted by the interpreter? A program is secure if it's behavior is predictable, given a certain set of actions.
Devin
and ugly colors!
Darn.. how much do we have to pay for a different color scheme?
Ack ... I meant to preview that post. Apologies for the (accidental) lack of spatial consideration.
Devin
And a blind guy would find even fewer security holes in assembly codes. So, let's hire only blind people to do assembly programming, and we'll have no security problems.
"Little does he know, but there is no 'I' in 'Idiot'!"
PINK, Pink, pink, PiNk, pInK,
*** PINK ***
pink.
Yep. The site is *pink*. This is what happens when you do color picking on a monochromatic monitor...
When I read articles in which they explain hundreds of coding techniques to make code secure, I really don't want to get involved with such languages. I am not a very good coder and for this reason, my favorite languages are Lisp, Python and O'Caml, all three languages have garbage collectors which frees me from a lot of work that has nothing to do with the task at hand. I know that I can't (and don't want to) deal with memory problems, so I use modern languages which think the programmer's time is more important than the computer's. Seriously, let's say I write an application to manage a little local computer store, why should I use C and potentially ship a lot of memory-related bugs with my app when I can use something like Lisp or Python or O'Caml which all are stable, complete and powerful languages in which that task would be easy and would result in a better application?
Last few places I worked at didn't care about security. They thought it only slowed down production and they wanted us to write code as fast as possible. I wasn't fast enough, so I got let go.
I tried to get into that website on security programming, and it said my user name already existed. How many Orion_Blastar accounts are there in the world, or is it a spoofer? So then I thought maybe I joined before and forgot about it, so I went to "Forgot Password" and got an error screen when I submitted it. Secure but buggy.
Remember, Slashdot does not have a -1 disagree moderation, and no, troll, flamebait, and overrated are not substitutes.
I hate to break this to you, but expecting a newly graduated kid to be a solid performer from day one is unrealistic. They never have been. You weren't. I wasn't. The kids going through now won't be.
Software development hasn't (yet?) developed any sort of "apprenticeship" framework for the new kids on the block to learn practical, real-world skills from old hands. Their knowledge is, inevitably, mostly theoretical. They won't understand everything that was in their course properly, and even if they do understand something in theory, they won't necessarily appreciate the practical implications. The best you can hope for is someone who enjoys their subject, and thus has developed good general knowledge of the field and perhaps done some relevant part-time or summer job work.
If you're taking people on who aren't up to the standards you require at the time, and you're suffering bugs down the line as a result, then you need to review your recruitment process with HR, and you need to review your training process with the line managers responsible for overseeing new starters. Failure to do this is just plain bad management, and bitching about how degrees are worthless "these days" is a rather pathetic attempt to pass the buck. In reality, the blame rests squarely on the shoulders of the managers who haven't developed their resources effectively, and addressing that basic problem is the only way you're going to improve the situation.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Upon reading the post I visited their site. But immediately received this warning from my Antivirus program (Norton). Is it just some Windows misinterpretation or what...
t ml appears to be infected with Virus name: Unix.Penguin
Virus Found!
Date found: Mon Sep 15 15:09:59 2003
C:\WINNT\Temporary Internet Files\Content.IE5\SPCX87YZ\secureprogramming[2].h
Please send report from the "bulp" on the intranet portal
(Danish: "el-paeren" - Swedish: "glodlampa" - Norwegian: "lyspaeren").
Problem type Virus.
Leave the machine switched on but don't use it for other purposes.
yes, I know the airforce still uses JOVIAL, but that is the only group that did, and it was a modified version of ALGOL, so you could say that it is a specialised language that borows a lot from ALGOL.
I am the Alpha and the Omega-3
How does this book compare to the Microsoft book on writing secure code? MS jokes aside, this would be helpful in deciding which to puchase.
a slashdotting improved a site.
Besides, a properly written Java app WILL have a try/catch block at some basic level to do a last ditch effort to intercept (and deal with) a normally fatal exception.
Ah, thanks for making my point for me. I can't count the number of times I've seen a Java app crash with a NullPointerException. I'm not talking about Billy's discount water-effects Applet, I mean the big stuff -- ERP systems and other critical things that are supposed to be written very carefully.
Not handling or badly handling exceptions in Java is caused by the same thing that causes buffer overflows in C: laziness. They crash because the programmer didn't think it was possible for something to go wrong there. Garbage in-garbage out applies no matter what language you use.
Take Java. Imagine an application that is set up to handle exceptions at the highest level, but the underpaid contractor who handled the authentication code didn't bother to do any of their own. So an exception gets thrown when verifying the user's password and gets caught by the upper level handler. That handler tries its best to recover from the fault, and ends up happily bypassing the authencation.
Ok, so that example is a bit contrived, but my point is that no language will save you from bad programming and the logic errors that result. What is needed is a mindset that anything can go wrong at any time and you need to be prepared for that.
The right tool for the task applies here too. I agree that for a GUI frontend, something like C++ or wxPython is probably a good idea. But for an OS or a database server or other things that can't afford the bloat, well-commented low-level code that is written defensively can be just as safe.
If you validate and/or escape your inputs, there's no security issue with having SQL right there in your web front end. The problem is that most languages people use for web front ends do not make it convenient to do this. See my map demo for a one-page SQL app with a view source link. The same idea that makes it secure can make a large app secure.
Unsinkable.
You can have it fast, accurate, or pretty. Pick any 2.
I think you are misunderstood. No one is going to do a basic GUI app with database backend using C. Thats just plain stupid nowadays. I'm not partial to Microsoft and I'm sure there is RAD tools for Linux and Mac, but for example, using VB and an small database you could virtually create a computer store management tool in 2 hours from start to finish if your decent with VB.
But that doesn't negate the value of C and C++ for other tasks. Use what is best for the job. I love C for my network programming projects where I can manipulate data at a lower level and more "nitty gritty" which is fun. But I'm also loving the idea I can quickly drag, drop, code a few lines and BAM I have a nice little GUI app done with VB.
Seriously, let's say I write an application to manage a little local computer store, why should I use C and potentially ship a lot of memory-related bugs with my app when I can use something like Lisp or Python or O'Caml which all are stable, complete and powerful languages in which that task would be easy and would result in a better application?
So you don't want to have memory allocation and pointer issues. Fine. That does not make your programs secure which is the end goal of secure programming in ____.
You still have issues of data/input validation, principle of least priviledges, secure (confidential and/or authenticated and robust) communications, sanitizing the enviornment, dropping unnecessary priviledges (and designing the program so it can drop priviledges early on before user/network client interaction), race conditions, error handling, and many many other tedious yet important issues.
If your a lousy programmer why program? Maybe instead of looking for languages that can tolerate your inept skills you should seek a new career?
"safe" and "compiled" aren't mutually exclusive. For instance, O'Caml and SML are both compiled languages that have safety (impossible to have buffer overflows, integer overflows, double-free, printf-bugs, and most other common security problems). They are very fast, so don't deserve the "interpreted" stigma. Java can even be compiled and run safely outside a VM.
Otherwise, I agree with you. Languages can't possibly fix every security hole. But if you look at the majority of holes that affect us daily (like the MySQL overflow on the front page of slashdot, or the numerous recent RPC holes in Windows), those would be gone, period.
> and those that think they're safe merely by using a particular programming language are in for a nasty surprise.
That's true, of course, but nonetheless languages make a huge difference.
In applications, buffer overflows, along with (recently) integer overflows, double-free bugs, and printf formatting bugs, are the most common source of exploitable holes by far. (Case in point: the MySQL buffer overflow currently on slashdot's main page, the several recent RPC vulnerabilities in XP, the recent OpenBSD hole, etc.)
All of these errors would be impossible to make in a safe language.
Yes, we still need security-conscious developers, and there are still many things to worry about. But if we can get rid of the vast majority of problems, automatically (and as a side benefit get to program in a modern high-level language, which makes many other things easier), why not switch? Just because it's not a complete solution?
returns :-)
"Dictionary_exception_error: word not found"
I would like to say that maybe focusing on buffer overflows and exceptions is missing half the security problems in the first place. I've seen problems (written by consultants from a BIG company, I might add) along the lines of:
- assuming that "surely if we only created links to the valid data, all parameters on the destination page will only be valid ones. No need to check anything again."
The result? If the user was willing to edit the URL, they could edit the administrator's password instead of theirs. Effectively _anyone_ could take over the site without exploiting any buffer overflows or null pointers, just a little URL editing.
- Assuming that "if we said 'description' in the input field's label, surely noone will try to input something else."
The result? Effectively anyone was able to input JavaScript or VB Script code, which would execute in an admin's browser, when said admin reviewed the user's application.
- Failing to even think about non-repudiation and accountability.
E.g., when a user cancelled their account, all data about that user was instantly wiped out. It was like that user had never existed, and most traces of their activity were lost for ever.
And so on, and so forth.
Basically I won't argue against your argument that "Java is _more_ secure than C++". That is true. Some problems you can avoid easier in Java.
But I would strongly advise anyone against extrapolating that to mean "we use Java, therefore we are automatically 100% secure." That's not true. The number of problem that Java protects you against, is barely the tip of the proverbial iceberg.
And even the parts where Java does protect you, retarded enough coding can turn those mechanisms into liabilities, instead of advantages. Retarded enough handling of RuntimeExceptions can bypass important code paths, and leave the system and/or its stored data in an inconsistent state. Sometimes an exploitable state, even.
Regardless of whether you program in Java or C or Assembly, you _still_ must carefully consider your options, assess threats, do code audits, and so on. Anyone who fails to do so, will have some very nasty surprises down the line.
A polar bear is a cartesian bear after a coordinate transform.
Mark G. Graff and Kenneth R. Van Wyk have tackled this subject in a great book Secure Coding. Rather than just a cookbook, it deals more with the steps developing and maintaing the actual code.
Amen. Most people's experience with modern languages ends with Java running on a VM, and yes, that is pretty slow. But not all safe languages run in a VM, and not all have as much overhead as Java. For instance, I often find ML to be as fast as or faster than C, and the code is much nicer.
C is nothing special when it comes to speed, and as processors become less and less like the machine model that C was designed against, it will continue to lose its hold. ML programmers will simply change the implementation of 'map' to do pipelining, parallelization, while C programmers will have to learn the magic way to write their 'for' loops so that the compiler can recognize that they are writing 'map'.
Though certain software really needs every last cycle squeezed out of it (Doom III?) manually, nobody wants to or needs to do that for an entire application. The vast majority of software should be written in a nice language where the compiler can do the tedious work for you, and leave the hard parts to you!
A great article on threat modeling by Microsoft's software security guru.
boycott slashdot February 10th - 17th check out: altSlashdot.org
This could perhaps be neccessary. Current micro kernel architectures isolate their parts using different adress spaces. The implementation is similar to unix processes and so quite easy, but commnuication is very expensive.
Java/.NET/etc. isolate "processes" (e.g. applets) via the type system. This idea could be brought to kernel space. When Java loads a class file, first the bytecode is checked. After that, the JIT-Compiler generates the corresponding machine code. This code is run directly by the processor. Although a Java programm is translated into machine code, it cannot break out of the VM, because it is checked by the verifyer in the first place.
There already exists a kind of verifyer for the Linux kernel, it's called kernel mode linux. Baesd on this technology a micro kernel like architecture would be possible, where all the servers are runnig in the same adress space and so can communicate very cheap (sending a message is just a procedure call in the same adress space). Security will be enforced completely by a sound type system. And this is the point, where a object oriented language would be neccessary.
The main problem for performance would be the code checker. But using the TPM chip, it could be possible to check the code once during installation, compile it to machine code and then digitally seal it. So open source and TCPA could finally profit from each other.
if mozilla would have let me finish....
...practicing, and
"A great article on threat modeling by Microsoft's
software security guru."
Wouldn't this imply that Microsoft actively
practices security?
implementing are two differnt things however.
boycott slashdot February 10th - 17th check out: altSlashdot.org
If you do need string and all that fun STL stuff, and don't want to worry about memory allocation, I think you need to use a language that is designed to do memory allocation for you, like Perl, Java, C#, Python, VB, etc...
I always thought the whole point of C++ was that you got to impose a somewhat object oriented look at a total control of memory and hardware, not to be an end all be all object oriented system. That is, C++ is the way it is because it is a systems and hardware language first, and an application language second. If you don't want to worry about memory, or worry about hardware, then you should not be using C++. C++ is if you are worried about hardware. Simply using STL and saying it will be fast because it is C++ ought to be the quintessential test for programming incompetence.
STL doesn't really offer any advantages, particularly for server side or performance programming. It's based on new, which is globally specific, not, context specific. That f--- the whole language up right there, because without some new context you don't have an elegant way to do thread specific allocators, etc, and out goes your speed right out the window because you have all these blocking heaps. To get these blocking heaps, you make your design even harder to debug. All of these thread intermingled allocations make it difficult to track down real leaks and bugs.
For me, in Commodity Server, I used a much different tack. I gave each thread a set of virtual memory backed structures. For the most part a vm vector works but I do use skip lists quite a bit, each with their own allocation context which is typically a thread.
For the most part, I don't really even --need--- a good old "string" that much. So, while STL makes it easier to have a set of bugs to do something, I think, it's better still to have a design where the bugs could not be introduced at all.
STL's sole reasons for existence is to solve people problems, not technological ones. If two developers are in a fight over whose collection template to use, STL is the dummy default.
PS: std::cout / std::cin are a silly workaround for real problem of fprintf (argument lists in C++ do not have a length!).
This is my sig.
Funny, I had pretty much the same idea... I use my own C library (which is called "secureStrings") for my programs for some time now (about one year), because it has always been my opinion, that things like strcpy() and strcat should become forbidden ;-). SecureStrings works on Unix, VMS and OS/400; i didn't try, but it probably also works on NT...
C or C++ is probably great, for writing very special code, such as kernel modules to support new hardware, or scientific software and such.
However, I think there should be a more secure programming language than C for commercial and for networking software.
Implementing things like a webserver, a data warehouse, accounting software, etc. in C/C++ can be extremly dangerous, and experience shows, that most programmers just can't do it the right way with C/C++.
On Mainframes and AS/400s most commercial applications are written in COBOL, and this is probably one of many reasons, why these systems usually don't get hacked.
However, COBOL is somehow unhandy (unconventional syntax)
On Unix you can hardly get something else than a C/C++- or a Java-compiler; there should be an Ada- or a Pascal-Compiler available for every Unix derivate.
Yeah, just imagine if those applications were written in C with printf, malloc, and strcpy!!! Though scripting languages do lower the "barrier to entry," meaning that a lot more novice programmers can start writing code, I think we'd be a lot worse off if we had those same folks writing CGI apps in C.
.. instead of ..
.. that would pretty much get rid of SQL injection problems, and make code easier to write and read, too.
Anyway, I do read bugtraq, and I find that most of these bugs actually are language-based. SQL injection attacks come because the API for issuing queries works on strings, instead of query data structures. If your where clause was
And(Equaln("ID", n), Equal("Password", p))
"id=" + n.toString() + " and password=" + p
Most scripting langauges, like perl, have similar problems in their system shell commands, since these usually use strings as the API intermediate rather than data structures. (Ie, perl lets you open a process by using "|" as the first character of the filename.) If the shell command had you pass a list of unescaped arguments, rather than forcing you to do the escaping yourself, this wouldn't be a problem.
PHP has some number of design bugs, like the ability to include headers from the internet (???) and treating undeclared variables as input from the query string. These often lead to bugs.
There are lots of other bugs to be made (XSS is not that serious unless you are using cookies for secure data, which you shouldn't), some of which are in the language and some of which aren't. Also, it is difficult to forsee what these stumbling blocks will be when designing a language. (Though I think I've outlined one general principle above: use common data structures in APIs, not unparsing and parsing of strings.) But, language is still an important issue in addressing the source of all sorts of bugs, be it C or PHP.
> "I assume that a sufficiently skilled [cracker] will be able to do anything not explicitly forbidden by the hardware."
Yes, hardware has a much better track record at being correct than software. I blame Stroustrup in part!
> So, the second rule is, recognize that most "levels of protection" and "access controls" in programming languages
If you mean "private" vs. "public," that's not what we're talking about. We're talking about your language having properties like safety, which means that the only person who gets to write code is the developer (not the remote user uploading shellcode!).
If there is anything we've learned over the past 50 years, it's that programmers aren't Gods, and can not predict all the uses their programs will be put to.
Programming with dynamic structures in C may be challenging, but the alternative is to create a program that is much, much, much, much less useful. Who going to use a "grep" that limits at 1024 chars per line nowadays? Who's going to use a "sort" that allocates 64KB per line, making even relatively small files overload the system memory and flop out to swap?
This sort of suggestion sounds all wonderful and stuff until you remember (or learn, if you never did before) that in the general case, static buffers means either extreme memory wastage or overflowing the buffers anyhow, and possibly both. Plus static buffers gets you nothing in C, because static or dynamic you still need to check whether you're overflowing it!
Folks, I'm pretty sure this was a Troll, not an Insightful post, and quite a lot of you got taken. You think this is such a wonderful programming style, why don't you try using it for a real program. You'll see why it's useless in short order. If you're lucky you'll still have a job after that little experiment.
(And finally, dynamic programming doesn't have to be hard. I write in Perl and Python and the last time I worried about a buffer's size explicitly was when we were concerned about how much disk it would take to serialize a data structure and keep it around. Use a real language and this concern goes away. Study up on optimization techniques and you'll see that you don't necessarily even have to pay a huge processor penalty, those are just artefacts of relatively naive implementations. (Note "naive" here does not imply "bad", it's just a descriptive adverb.))
That's not really security then is it? It's kind of like the oxymoron that was "cooperative multitasking".
...although the converse is admittedly true AFAIK.
You're worried about runtime size and you're recommending Smalltalk? Furrfu! What about OCaml or Eiffel? Heck, even Perl has a smaller memory footprint in some instances than Smalltalk -- and you can do OO in Perl, although it doesn't force you to.
Lisp and Python has both byte-compilation and interactive-loop interpretation. If you haven't tried yet the interpretation mode in Lisp that doesn't mean it doesn't exist in Lisp. It's even described in most of Lisp books I've seen. It's very convinient when you need a sort of interractive debug mode.
I agree that Python byte-compiled code is still not as fast as C. However, in most of application (if they are not mission critical kernel drivers or DB engines) you don't really need to squeeze that performance. But I would not say that Python bytecode is always THAT slower than Lisp bytecode.
Less is more !
Because I like to solve programming problems, I like to program. Trying to figure out why my program has a memory leak is not fun. Doing stuff is. If your definition of a programmer is someone who writes C code and loaths other programming languages because you can't shoot yourself and the whole world in the foot with it, well stay an anonymous coward and go back to writing crappy software loaded with bugs
1. Since the library automatically resizes its strings including the base pointer, that means if you have multiple refs of a string, then manipulations of one of them may leave others in an undefined state. For example:2. The use of SAFESTR_TEMP() (a string that automatically disappears after being passed to any safestr function) is clever but necessarily prevents any of the SafeStr functions from accepting const parameters. This has an additional problem that if you write a function which accepts a safestr_t, then if you pass it to
one safestr function its reference might become undefined (you can't know.) For example:********
If you want to use an actually usefully architected string library try mine here:
http://bstring.sf.net/
In a direct comparison with safeStr, it should be pointed out that bstrlib doesn't have any concept of a "tainted" string. However, it does support read-only strings. bstrlib does not have any of the basic architectural weaknesses described above. It also has numerous other important features which are summarized here:
http://bstring.sf.net/features.html
Half-truths. Both C and C++ can support strings without buffer overflows through nice string libraries. It's just people don't use them as often as they should. Standard C library is a piece of crap as far as strings and type safety are concerned, not the whole language.
With more compile-time analysis, pointers can be automatically assigned attributes, like
-
No pointer arithmetic ever.
-
Always points to the heap.
-
Always points to the stack.
-
Always points to a static variable.
-
Never null.
With information like that, more optimizations are possible.Another key optimization is that the compiler needs to know that it's OK to detect a subscript error early. If a loop will overflow an array on the last iteration, but that overflow is inevitable at loop entrance, that error should be reported before the loop starts. To do this, the compiler needs to be able to hoist checks out of loops, even though that may change when the program aborts. This is key to getting the checks out of of inner loops.
With more work in this area, it would be quite possible to reach the point where trusted C and C++ software was running with full checking but only 20% or so additional overhead. It was done for Pascal in the 1980s, after all.
> You're worried about runtime size and you're recommending Smalltalk?
There are slim Smalltalk implementations, but the real issue is that Smalltalk is conceptually clean. You could take Oberon or whatever; just don't take an ugly hack of a language.
> you can do OO in Perl, although it doesn't force you to.
OO in a procedural language is an ugly hack... that's why Smalltalk or functional languages are so much better.
Leandro Guimarães Faria Corcete DUTRA
DA, DBA, SysAdmin, Data Modeller
GNU Project, Debian GNU/Lin
I see very little difference, to be honest.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
I don't mean just private-vs-public (although some misguided folk wish those were security related). Attempts like "safety properties" strike me as just giving a warm fuzzy feeling without doing much beyond security-through-obscurity. How does a piece of software know I'm a developer rather than an intruder? If I poke bits into the proper places in memory, software will believe anything I tell it to believe.
I'm not advocating avoiding such research, but I have yet to see anything that isn't just being touted as "this silver bullet will make your problems all go away".
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
No, it's not arguable, here's some stats. However it doesn't require a new language to solve this problem.
This is very true, if only Universityies offered something like "CS 104 - Thinking like an adversary", which is a bit different from how programmers normally think about their code. Ahh. well, someday.
ustr: Managed string API with ave. 44% overhead over strdup(), for 0-20B
grep / sort bad examples
if (little file) memory_map_it.
That's one allocation. And you would do an allocation per line? Boy that's silly. In this scheme, there is no overflow.
If the file is too big or over a threshold, probably should require some extra priviledges to sort.
swap file argument red herring
Most applications have no control over when the O/S swaps out a physical page. I will tell you that if you are doing stuff with the VM, you are going to know exactly at least the locality of things getting swapped out.
dynamic optimization
I love this. The argument is that dynamic allocation does not pay a huge processor penalty. By definition each allocation is a search. If you have a perfectly sorted heat, then your time is O( log n ). That is, you program's performance decays with the amount of data. If, on the other hand, I do a clever thing and get an O( 1 ) serach, then, as I would if my next free block were a simple pointer addition, then, I pay little CPU tax at all.
Now granted, I program in Perl myself, and C#. And, again, I made the point that if you program in a language that supports dynamic programming, then, go for it. But, the discussion was about C++ and my point is that if you are going to program in C++, then go for fixed size records.
PS. If you program in Perl and are just doing while , then, you've opened yourself to a DOS attack. Duh.
This is my sig.
Attempts like "safety properties" strike me as just giving a warm fuzzy feeling without doing much beyond security-through-obscurity.
Like well-designed hardware, a language can provide you with an abstraction that you can depend on. In particular, safe languages can do things like guarantee the sanctity of an abstract type, or assure you that your program has no "undefined behavior" (i.e., a security hole). These are impossible in C, and are often what underlies security holes, and indeed, many bugs in general. It's not security through obscurity; it's security through security.
but I have yet to see anything that isn't just being touted as "this silver bullet will make your problems all go away".
Well, you've called on two catch phrases, but you haven't explained how they apply to languages. In what sense don't languages like SML (or, hell-- Java, Dylan, ADA, Lisp, or any of the other safe languages proposed by slashdot posters) solve all of your buffer overflow problems? (And double-free, integer overflow, etc. problems) Have you even used such languages?
Because they're impossible in general. See "halting problem, the".
In the sense that the VM is just another piece of software, capable of being attacked and exploited. Like I said previously, these languages are great in and of themselves, and certainly help solve common programming errors, but they're still not the end-all-be-all solution.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
Because they're impossible in general. See "halting problem, the".
Uh, what? Yes, most properties of programs are undecidable. Nonetheless it's simple to have a language that guarantees various properties, it just can't be exact. ML and other languages with static safety properties work by excluding all of the programs that are unsafe -- and then some others. The others are typically programs you don't want to write (because their correctness depends on some unclear criteria). At the expense of excluding some strange programs, you get a decidable property that IMPLIES the relevant safety properties.
Anyway, properties like not writing outside the bounds of an array are checked dynamically in almost every safe language. Those properties are guaranteed exactly, because they are semidecidable. You don't need decidability if you catch them at run-time. (On the other hand, you don't know if your program has such a bug until it's triggered.)
In the sense that the VM is just another piece of software, capable of being attacked and exploited.
Half of those languages don't even run in a VM. They are compiled like C, thus subject to the same set of "system" security holes (hardware bugs, kernel bugs, compiler bugs, and system library bugs).
You're jumping to (incorrect) conclusions a lot. I recommend you open your mind and try some new languages!
I think we were using different definitions of undefined behavior. I don't necessarily disagree with you, but it seems you're talking about a different problem domain than I am. And that's okay.
As far as conclusion jumping, closed minds, and needing to try those languages, sorry, you're flat wrong. :-) I've already tried those languages, and just wasn't impressed. They're useful, but I think we get more security by focusing our attentions elsewhere.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
Also, I think Jovial is used by the current Air Traffic Control system, so it's not only the Air Force that's using it.
What I was hoping to suggest is that languages that define their own hardware (through VMs, or potentially through a hardware implementation of that VM) have more of a chance to enforce a concept of "security" not easily broken by the developer's code running inside the VM.
That is, security could be actually enforced, rather than being just a conceptual help.
I'm not saying VM-based languages enforce "real security", whatever that means in each context.
But that would blur the conceptual barrier suggested in the quote, that any such security requires dedicated hardware.
Freedom is the freedom to say 2+2=4, everything else follows...
LISP was designed by McCarthy not for natural language processing--that wasn't even a field of study back in the '50s when he invented LISP--but purely for academic research. Here's the thing: while the Universal Turing Machine is a complete model of computation, it sucks for anything outside of toy theoretical problems. The UTM is simply too awkward and kludgy a model. Is it complete? Yes. Is it accurate? Yes. Is it unspeakably gross? Yes.
Alonzo Church developed a competing computational theory called the lambda calculus. The lambda calculus is a complete computational model, and it's breathtakingly simple and elegant. Really; going from the UTM to the lambda calculus is like going from darkness into light.
So in the '50s, the lambda calculus was still reasonably new. McCarthy decided to make a totally theoretical language--one which was never intended to be implemented--to allow algorithms to be expressed in lambda form, the better to analyze them for correctness, runtime analysis, etc.
Not long after McCarthy wrote the language description, an enterprising graduate student actually figured out a way to implement LISP on real hardware. And thus, McCarthy's LISP was born (aka LISP 1.5).
Natural language processing came along much later, in the '80s. AI researchers used LISP extensively not because LISP was designed for AI, but because LISP had the greatest flexibility and power of any language of the day.
In fact, I'd be hard-pressed to name any languages today which can beat LISP in power and flexibility. There are a few worthy contenders, but almost all of the worthy contenders build on LISP's heritage instead of representing entirely new directions in computer science.
Before you go about slamming a language, you may wish to learn the language's history.
"I think I am a fallen star. I should wish on myself."
I've already tried those languages, and just wasn't impressed.
You did? Then why did you think they ran in a VM? Why did you not know what kind of security properties they have?
I'd like to know who the moderators were that modded this as flamebait and troll. That was classic!
i don't believe i said that.
i also don't believe there's a point to this conversation. and i've just started usksing a pressure-sensitive touchpad instead of a normal keyboard, so i'm not going ti waste an time startging a flamewar while relearning how to type.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
i don't believe i said that.
You said it in this post.
i also don't believe there's a point to this conversation.
Well, I didn't mean for it to be a flamewar, but, ok.