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."
gathers GAY NIGGERS from all over America and abroad for one common goal - being GAY NIGGERS.
Are you GAY ?
Are you a NIGGER ?
Are you a GAY NIGGER ?
If you answered "Yes" to any of the above questions, then GNAA (GAY NIGGER ASSOCIATION OF AMERICA) might be exactly what you've been looking for!
Join GNAA (GAY NIGGER ASSOCIATION OF AMERICA) today, and enjoy all the benefits of being a full-time GNAA member.
GNAA (GAY NIGGER ASSOCIATION OF AMERICA) is the fastest-growing GAY NIGGER community with THOUSANDS of members all over United States of America. You, too, can be a part of GNAA if you join today!
Why not? It's quick and easy - only 3 simple steps!
First, you have to obtain a copy of GAY NIGGERS FROM OUTER SPACE THE MOVIE and watch it.
Second, you need to succeed in posting a GNAA "first post" on slashdot.org, a popular "news for trolls" website
Third, you need to join the official GNAA irc channel #GNAA on EFNet, and apply for membership.
Talk to one of the ops or any of the other members in the channel to sign up today!
If you are having trouble locating #GNAA, the official GAY NIGGER ASSOCIATION OF AMERICA irc channel, you might be on a wrong irc network. The correct network is EFNet, and you can connect to irc.secsup.org or irc.easynews.com as one of the EFNet servers.
If you do not have an IRC client handy, you are free to use the GNAA Java IRC client by clicking here.
If you have mod points and would like to support GNAA, please moderate this post up.
This post brought to you by Penisbird , a proud member of the GNAA
G_____________________________________naann_______ ________G
N_____________________________nnnaa__nanaaa_______ ________A
A____________________aanana__nannaa_nna_an________ ________Y
A_____________annna_nnnnnan_aan_aa__na__aa________ ________*
G____________nnaana_nnn__nn_aa__nn__na_anaann_MERI CA______N
N___________ana__nn_an___an_aa_anaaannnanaa_______ ________I
A___________aa__ana_nn___nn_nnnnaa___ana__________ ________G
A__________nna__an__na___nn__nnn___SSOCIATION_of__ ________G
G__________ana_naa__an___nnn______________________ ________E
N__________ananan___nn___aan_IGGER________________ ________R
A__________nnna____naa____________________________ ________S
A________nnaa_____anan____________________________ ________*
G________anaannana________________________________ ________A
N________ananaannn_AY_____________________________ ________S
A________ana____nn_________IRC-EFNET-#GNAA________ ________S
A_______nn_____na_________________________________ ________O
*_______aaaan_____________________________________ ________C
um, dolor. Nunc nec nisl. Phasellus blandit tempor augue. Donec arcu orci, adipiscing ac, interdum a, tempus nec, enim. Phasellus placerat iaculis orci. Crasa sit amet quam. Sed enim quam, porta quis, aliquet quis, hendrerit ut, sem. Etiam felis tellus, suscipit et, consequat quis, pharetra sit amet, nisl. Aenean arcu massa, lacinia in, dictum eu, pulv
*Pukes*
Some of you here on slashdot may be familar with the Venus 2000, a penile stimulation device.
Read on...
Due to a freak accident that happened when Penisbird (me) and Jew Unit tried to modify our Venus 2000's to work directly over Token Ring, a short occured and a massive power surge resulted in my Venus 2000. The short destroyed my Venus 2000 and the only thing that saved me was the thick rubber condom I was wearing at the time.
Please reply in the goatse.info article, or send replies and pictures to penisbird@nero-online.org
These security problems are fixed by switching to a modern language like Java or C#.
There is really no excuse to use C and C++ in this day and age except that the programmer in question is too lazy to learn newer and better ways to program.
No one uses Algol anymore. No one ought to be using such outdated languages as C and C++.
Netcraft reports that Goatse.cx is running IIS/5.0 on Linux. Repeat: Netcraft reports that Goatse.cx is running IIS/5.0 on Linux.
Now back to your regularly scheduled article.
The Gay Nigger Association of America (GNAA) is the group that represents the world's Gay Nigger population as well as those non gay, non nigger patrons that support it. Its mission is to foster a gay and free-loving climate that supports and promotes our members' creative and financial vitality. Its members are the gay niggers that comprise the most vibrant national gay nigger conglomerate in the world. GNAA members create, manufacture and/or distribute approximately 90% of all legitimate pro-homosexual propaganda and blue, rubber dicks produced and sold in the United States.
We strongly urge you to join the GNAA and support our cause. Gay Niggers everywhere need your help!
BE NIGGER!
BE GAY!
JOIN THE GNAA!!
Join #GNAA on the EFNet IRC Network today! (irc.secsup.org, irc.easynews.com, irc.servercentral.net)
________________________________________________
| ______________________________________._a,____ |
| _______a_._______a_______aj#0s_____aWY!400.___ |
| __ad#7!!*P____a.d#0a____#!-_#0i___.#!__W#0#___ |
| _j#'_.00#,___4#dP_"#,__j#,__0#Wi___*00P!_"#L,_ |
| _"#ga#9!01___"#01__40,_"4Lj#!_4#g_________"01_ |
| ________"#,___*@`__-N#____`___-!^_____________ |
| _________#1__________?________________________ |
| _________j1___________________________________ |
| ____a,___jk_ GAY_NIGGER_ASSOCIATION_OF_AMERICA_|
| ____!4yaa#l___________________________________ |
| ______-"!^____________________________________ |
` _______________________________________________'
-posted by GNAA member Penisbird
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.
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.
I wonder how long until slashdot's resident MANHAM CANNER shows up to weigh in on this subject with something obnoxious and/or subtly to grossly wrong.
Posted from the nero-online.org Troll Library Following my work researching The Linux Gay Conspiracy, I am saddened to announced that I have discovered yet another orgy of perverted heterophobic values. My claim lies with the Slashdot mangement. First, what kind of name is Slashdot? This is obviously a code word in the homosexual community for something perverted. Slashdot is an anagram of LAD SHOTS, which refers to Slashdot's pedophile agenda and T ASS HOLD, which refers to some gay sexual posistion that Michael and CmdrTaco enjoy. The 'editors' of Slashdot, as they call themselves, are homosexual swingers with cleverly disguised nicknames. CmdrTaco (aka "Rob" Malda) is the "head" honcho of Slashdot. Cmdr obviously refers to his desire to dominate over his gay partners, and Taco is obviously a sly reference to his colon. Update: It is well known that Taco claims to be married to Kate Fent. No one really believes that 'she' is actually his wife. We have proof that this 'she' is actually a he. It turns out that Kathleen Fent is an anagram of KHAN FELT EN ET. So this Kate of his is really Khan who "felt in it". I will not describe what that means as I am sure you can imagine yourself.Update From AC: Kate Fent = FAT TEEN, K. Michael Sims, who goes as 'michael' on Slashdot, is a well known thug and advancer of homosexual agenda. His name is an anagram of ASS CHIME MIL which obviously refers to his desire to flaunt his lower organ.Update: It turns out that Michael Sims is also an anagram of ASS LICE, HMM, I?. That is so sick that words cannot describe the horror. Father Randy "Pudge" O'Day is Slashdot's Mac propagandist. Macintosh computers are well known as the Gay computer due to their homosexual colors and stylings. An email exchange between 'Pudge' and Apple HQ have been leaked by a former Apple employee who converted to heterosexuality. These two emails (here and here) have been repeatedly posted on Slashdot, but are quickly censored by Slashdot moderators who do not want the public to know about its agenda.Update form Subject Line Troll - it appears the O'Day is just a few letter changes away from I'm Gay and rhymes with O'Day. Is anyone surprised that Mr. Pudge is a fudge packing Mac hippie? Simoniker, a recent addition to Slashdot has been uncovered as Mr. Goatse himself. Simoniker is a frequent poster to the Games section of Slashdot, obviously because he enjoies modded versions of Quake 3 and UT2K3 as a homosexual warrior who likes to 'overcome' his opponents with his exagerated sized love member. In addition, Simoniker is an anagram of KEN I RIM SO (Ken is probably his current boyfriend) and MEN I IRK SO (which refers to his frustratingly troubled gay relationships, probably due to his rather large asshole).Update from AC: I'M ON ERIK'S... "Eriks what? We can only imagine" -AC. CowboyNeal. How could I forget him? CowboyNeal is Slashdot's Poll Editor. His rampant homosexuality is obvious. "Cowboy Kneel" is what his name actually means. His odd sexuality needs no further explanation. Please reply with additional information, contributions, and corrections. I will include any additional information and credit you with it in my further releases of this report.
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.
Posted from the nero-online.org Troll Library
Following my work researching The Linux Gay Conspiracy, I am saddened to announced that I have discovered yet another orgy of perverted heterophobic values. My claim lies with the Slashdot mangement.
First, what kind of name is Slashdot? This is obviously a code word in the homosexual community for something perverted.
Slashdot is an anagram of LAD SHOTS, which refers to Slashdot's pedophile agenda and T ASS HOLD, which refers to some gay sexual posistion that Michael and CmdrTaco enjoy.
The 'editors' of Slashdot, as they call themselves, are homosexual swingers with cleverly disguised nicknames.
CmdrTaco (aka "Rob" Malda) is the "head" honcho of Slashdot. Cmdr obviously refers to his desire to dominate over his gay partners, and Taco is obviously a sly reference to his colon. Update: It is well known that Taco claims to be married to Kate Fent. No one really believes that 'she' is actually his wife. We have proof that this 'she' is actually a he. It turns out that Kathleen Fent is an anagram of KHAN FELT EN ET. So this Kate of his is really Khan who "felt in it". I will not describe what that means as I am sure you can imagine yourself.Update From AC: Kate Fent = FAT TEEN, K.
Michael Sims, who goes as 'michael' on Slashdot, is a well known thug and advancer of homosexual agenda. His name is an anagram of ASS CHIME MIL which obviously refers to his desire to flaunt his lower organ.Update: It turns out that Michael Sims is also an anagram of ASS LICE, HMM, I?. That is so sick that words cannot describe the horror.
Father Randy "Pudge" O'Day is Slashdot's Mac propagandist. Macintosh computers are well known as the Gay computer due to their homosexual colors and stylings. An email exchange between 'Pudge' and Apple HQ have been leaked by a former Apple employee who converted to heterosexuality. These two emails (here and here) have been repeatedly posted on Slashdot, but are quickly censored by Slashdot moderators who do not want the public to know about its agenda.Update form Subject Line Troll - it appears the O'Day is just a few letter changes away from I'm Gay and rhymes with O'Day. Is anyone surprised that Mr. Pudge is a fudge packing Mac hippie?
Simoniker, a recent addition to Slashdot has been uncovered as Mr. Goatse himself. Simoniker is a frequent poster to the Games section of Slashdot, obviously because he enjoies modded versions of Quake 3 and UT2K3 as a homosexual warrior who likes to 'overcome' his opponents with his exagerated sized love member. In addition, Simoniker is an anagram of KEN I RIM SO (Ken is probably his current boyfriend) and MEN I IRK SO (which refers to his frustratingly troubled gay relationships, probably due to his rather large asshole).Update from AC: I'M ON ERIK'S... "Eriks what? We can only imagine" -AC.
CowboyNeal. How could I forget him? CowboyNeal is Slashdot's Poll Editor. His rampant homosexuality is obvious. "Cowboy Kneel" is what his name actually means. His odd sexuality needs no further explanation.
Please reply with additional information, contributions, and corrections. I will include any additional information and credit you with it in my further releases of this report.
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.)
Gullible? Oh yea, get wound up Suzy, you're just another victim, you little emotional girl..
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!
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
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.
Look boys and girls, it's very simple. There are lots of things you need to do to increase the security of your programs. And many of those things are language-agnostic. But a great many are not. Lesson #1 is: DON'T USE C OR C++.
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.
Sure, people will say "oh, yeah, but you can be insecure in any language". These people should have their CS degrees revoked. Just because any pet can be theoretically dangerous doesn't mean we should go ahead and buy grandma an alligator. Pick tools that will give you the best chance of being secure, all other things being equal. And all other things being equal, C/C++ is MUCH MUCH MUCH less secure than Java. Or Lisp. Or Python. Or Ruby. Or ML. Or Haskell. Or Smalltalk. Or Pascal. Or Modula 3. Or Simula. Or NewtonScript. Or [grak] Perl....
www.cgisecurity.com/lib large library of documents
Secure java development
Secure XML
Secure Web Services
"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
However, since I already own at least one of your books I'll check it out.
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?
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
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&cate gory=191&item=3626606896
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
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.
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.
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...
--
-- 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
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.
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.
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"
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.
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.
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'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.