Slashdot Mirror
Blame Bad Security on Sloppy Programming
CowboyRobot writes "ACM Queue has an article that blames security flaws on poor programming, rather than any inherent problems with particular languages.
From the article: 'Remember Ada? ... we tried getting everyone to switch to a 'sandboxed' environment with Java in the late 1990s... Java worked so well, Microsoft responded with ActiveX, which bypasses security entirely by making it easy to blame the user for authorizing bad code to execute.'"
Does anyone feel that this is just publicizing what every GOOD developer has been saying for the last 10-15 years?
Disconnect and self-destruct, one bullet at a time.
"Microsoft responded with ActiveX, which bypasses security entirely by making it easy to blame the user for authorizing bad code to execute"
.NET is their response to Java (and, for all intents and purposes, .NET is miles ahead of anything MS has ever created in terms of security).
Uh, not quite. ActiveX was more a response to JavaScript/Flash/et al. Anything that created a lightweight web app.
Anything we do to improve software security must work without the programmer having to switch languages
I agree; it's not so much the language--or the tools--each developer on a project must be personally aware of vulnerabilities and exploits. Using "managed code" does not "secure" your projects. These days, a C programmer ignoring the dangers of gets(), for example, is incompetent and should not be trusted. It's not, as the article reads, "sloppy"... it's ignorance pure and simple.
Also, relying on tools like an updated gcc, gprof, or splint--helpful as they are--without experience and education in writing secure code... is asking for trouble also.
Sigs cause cancer.
If Java worked well, it wouldn't be one of the languages that a ton of people hate to work with because of how annoying it is... granted, that is due to the poor VM rather then the problems within the language itself...
I guess I should be an anonymous coward right now as I'm sure all the people who think Java is 31337 and open source will come and mod me down
> ...if you can just shoot the message?"
So true. Thus the logo for PMD, a Java static analysis tool - "don't shoot the messenger".
The Army reading list
Java's main problems with being taken up I don't think had a thing to do with Microsoft, but more with the lack of Sun wanting to open up Java more to make it a free standard. Instead, Sun wanted to license it.
I resemble that remark!
Like with perl, I'm not always wanting to use strict and warn; I like not having to predeclare all my variables, for one thing...(and sometimes I'd have to lookup how to predeclare some kinds of hashes and arrays...)
SO YOU'RE GOING TO DIE: The Comic for Dealing with Death
I blame bad security on the Speak'n'Spell keyboards we have to use in this office.
I remember the bad ol' days when security was a matter of what you did or didn't do rather than what you didn't know was occurring without your knowledge!
Abstracting the user from programmatic events wasn't supposed to make your use of the computer a crap-shoot.
Mod me troll, if you must, I can't help it.
It is time to create an official Engineering Certification for software designers/developers, the certified Engineer will have to be financially responsible (insurance etc.) for their creations.
I would like to see that happen, anyone else?
You can't handle the truth.
ActiveX definately seemed made to to make web applications before Microsoft realized that might not be a good idea. Hence DHTML has practically died with IE having no real updates since IE4.
That's why OpenBSD's continuous code auditing makes for good security. Everything but the kitchen sink != better.
That all said, a sandbox environment allows the developer to make sloppy mistakes, not program better.
Trolling is a art,
The same is especially true in PHP. The short learning curve for getting started in the language allows for a great deal of insecure coding on the internet. I run a site that promotes secure programming, and is running a security challenge for writing scripts as well. The URL is http://www.uberhacker.com
Figure this - code is only as good as the coder.
This sig no verb.
Okay, it's the happy-fun Slashdot thing to talk about how retraded 'lusers' are. Almost as hi-larious as jokes about Clippy and rebooting Windoze machines.
But you know what?
Most developers are retraded too.
This probably includes you, my friend, as you read it in your grease-stained Manga t-shirt. This is not a problem that will be solved by yelling at people about bad code - they're going to produce it anyways, and in droves. The solution to dumb users is good UI design and a sensible permissions architecture. Similarly, the only workable solution to this problem is architectural.
Google confirms: Ruby is the world's most beloved programm
I'm not really a code guru, just some scripts, and the few programming courses I took in college. But I think this falls under the same category as the various anti-copy technologies. Where there's a (malicious) will, there's a way. I mean, certainly, the tighter and more secure your code is, the harder it will be to find a way to exploit it, but really, those wishing to do bad things always find a way.
(Note: I'm against anti-copy technology, just using it as an example.)
When will we see "ACM Queue has an article that blames security flaws on HR departments and middle management?"
When you're in college, the graders are not trying to break into your application, they're just evaluating the source code and give you points for correct stack and linked list implementation. Thus giving a false assurance that the real-world development is pretty much the same - friendly and non-threatening environment, no need to check and validate input, no need to resort to minimum security permissions and so on.
I think Caustictech said it better than I can:
a bad workman always blames his tools.
Drill baby drill - on Mars
A lot of problems result from the C and C-like languages' inherent faultiness. The language is a great way of writing "portable assembly language", but makes for sloppy code a lot of the time, even from relatively experienced programmers. It's mainly due to the "New Jersey" approach to development.
C++ and C are very popular and widely used, and will probably never fade completely as they are too entrenched, however, there are a lot of languages these days with compilers which can produce code as tight and fast as C/C++, but without the mess. This is one example, there are many others.
Brandon Glass's personal site.
Are you crazy?
Anyone who's worked on a software project of any size (especially in terms of number of people on the project) can tell you that the person who takes the official blame for a development flaw is almost never the person actually responsible for it.
Maybe if we had a programmers union and I could strike if I was ever asked to implement bad design or put out someone else's fire... maybe. But as things stand? You'd drive a lot of good developers out of the field because they're not skilled enough at office politicking to avoid being made scapegoats for the messes of others, and can't afford to bear the direct financial burden of it.
I'm glad someone other than me (who can get published on a site slashdot will link to) said it:
Compilers shouldn't generate warnings, they should generate errors.
It's time to stop holding the programmer's hand. If I write a C program that makes 5 malloc() and 4 free(), the compiler should notice that and say, "Gee, you have a memory leak here" and refuse to compile. It should NOT say, "Well, what you're doing is provably unsafe and probably not what you want, but yes sir Mr. Developer, I'll happily crash the system for you!" It is NEVER correct to write unsafe code.
I understand that there is a certain laxness built into C to make it easy to port to multiple platforms, etc., but these were compromises made in the early 70s, ffs. How long must we live with choices made under circumstances that became outdated 20 years ago?
"Honey, it's not working out; I think we should make our relationship open-source."
While it's easy to rip on the idea behind ActiveX, Mozilla.org thought it was a good enough idea to copy it as XPI*.
The basic idea is that plugins and toolbars should be easy to install, and due to the nature of these things, they often can not be "sandboxed" or run in a Java VM. One of the big complaints about Mozilla is that people find it difficult to install the Flash/Java/Real plug-ins. If vendors supported XPI, this would be mostly resolved.
The real security problems with IE are not directly related to ActiveX, but instead the holey and flawed "zone" system. There's also some operational annoyances with ActiveX (like throwing up dialogs even though ActiveX is disabled and the lack of an easy way to whitelist), but it sounds like XP SP2 is going to try to fix some of those things.
* ? Apologies if I'm confused about the moz alphabet soup.
Business. Numbers. Money. People. Computer World.
Fatal error: Call to undefined function: message_die() in /var/www/acmqueue.com/htdocs/db/db.php on line 88
I doubt outsourcing all of our coding to India is really going to help make more secure programs either.
I only wrote it because that is what was in the requirements.
Eventually all of this will be irrelevant because HW will have so far outstripped the requirements of software that we'll just run all of our programs on emulators on the hardware. That will fix not only the security problems, but it has the added bonus that since you'll be able to get all emulators for all platforms, there won't be any compatability issues -- everything will be truly platform independent.
"Lawyers are for sucks."
- Doug McKenzie
... not 'retraded'
Wow, that's priceless. Here you are complaining about how retarded developers are, and you spelled retarded wrong. "retraded" my ass.
But there is another kind of evil that we must fear most... and that is the indifference of good men.
If you see a warning, get rid of it right away! Once you slack off a bit, it becomes like dirty dishes piling up in the kitchen sink. Nobody wants to touch them, and everybody feels like most of them are the other roommate's anyway.
This is what I saw instead of the article:
/var/www/acmqueue.com/htdocs/db/db.php on line 88
Fatal error: Call to undefined function: message_die() in
From my load of page 2:
/var/www/acmqueue.com/htdocs/db/db.php on line 88
Fatal error: Call to undefined function: message_die() in
Physician, heal thyself...
...for spurious conclusions and poor research. Note: I haven't read the article, but the whole Java begat ActiveX is so off base, I suspect I'm not missing anything.
The weakness of Ada is its woefully outdated standard libraries which are more oriented to a 1960s mainframe view of the world. There are no containers, no STL, no general algorithms. That is the weakness of Ada.
If Ada had the powerful standard libraries which C++ has, that combined the safety of Ada would make it a first choice for many programming tasks. Ada can still deliver on bug free programming. But it lacks the scaffolding needed for 21st century projects.
I know though that really wasn't you were implying just kinda reminded of the ACM Programming Contest (so if you need programs coded quickly and pass all tests call up the St. Petersburg Team).
Most security issues are a combination of Bad Specs and Limited Time (where Time==Money) That truely make a program insecure.
Companies are afraid to make the Specs simple they want the program integrated, customizable and expandable. And all that other good stuff so programmers are forced to make their application very dynamic which makes the program more complex and open for security issues. But combined with these specs they are not willing to pay the programmer for all the time is needed and they get very annoyed when the programer is over budget. So the programmer in order to keep his job will find short cuts to make the programming time faster (Hoping the product will be used in a well protected network. But of course once the program is completed they decide to use it outside the normal specs and put it on a hostile network.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
I hardly find this news on Slashdot.
Many of us ./ers program in some capacity and have varying experience. However, it should be understood that a language is not inherently secure (neither is an OS!). It may have features that make is appear more security conscious, but it does not make the code impregnable.
A car has seat belts and air bags, but that won't prevent an accident or serious bodily injury. It definitely won't prevent someone else from slamming into you.
Good programming starts in the design. Careful attention to the UI is a must as well (think Driver's Ed!).
Oh! And check those buffers!!!
Not that i really know anything about .NET, but i recall reading articles which mention that .NET allows you to call on undocumented API's. They might not create direct threats, but we've seen hacks that utilize two or three exploits at the same time. I could be wrong, so feel free to follow up with why.
[Fuck Beta]
o0t!
Didn't even finish reading the article before: /var/www/acmqueue.com/htdocs/db/db.php on line 88
Fatal error: Call to undefined function: message_die() in
-
char s1[80];
...
which has a risk of buffer overflow, becomesvoid foo(char* out, char* in)
{ sprintf(s,"In = %s\n",in); }
-
char_string<80> s1;
...
which will truncate the string at the specified length. Note that the "sprintf" line hasn't changed. So you don't have to rewrite complex formatting code. Changing the declarations does the job.void foo(char_string_base& s)
{ sprintf(s,"In = %s\n",in); }
The new "sprintf" is actually an overload on fixed_string.
Gah, you know you've been brainwashed by a phrase when you see all-your-fault
and you immediately complete it with "are belong to us."
------
"And may your days be long upon the earth."
The security advantage of some langages is that it makes it EASIER to write secure code, not that they make it impossible to write insecure code. There's a difference between protecting you from accidentially shooting yourself in the foot and preventing you from intentionally aiming at your foot and pulling the trigger.
It is possible to write secure code in C or C++ -- but it takes a whole lot more effort and talent to get it right than it would to do so in a language which does automatic bounds checking and runs in a sandbox. Unfortunately, history has shown us that it's extremely difficult to write secure C/C++ code -- only a handful of programmers are able to consistently get it right, and even the best of the best still make basic mistakes.
Why is it that the proponents of "one nation under God" are so eager to get rid of "liberty and justice for all"?
...this business will be populated exclusively by highly-competent professionals WILL NEVER BE SECURE. Security must be enforced automagically. If we depend on those writing code, we will never have security.
Speaking as a computer engineer who passed the FE (on my first try) - the FE is most definitely biased in favor of civil and mechanical engineers, and against electrical and chemical. That being said, there's really very little incentive for EEs to take it. The only things you need it for are government work or testifying in court.
However, it really gets under my skin when people call themselves "engineers" and they have *no clue* about engineering in general. In texas, they had a school collapse and kill 100 children because the guy who designed it wasn't a real engineer. As a result, they passed the toughest engineering-standards legislation in the country - if you call yourself an engineer and you are not certified (that is, you have not passed the PE) then you go to jail.
To make laws that man cannot, and will not obey, serves to bring all law into contempt.
--E.C. Stanton
Here is the English version of the above link.
Brandon Glass's personal site.
It might be the effects of /. but while I was trying to re-link the url I get this...
/var/www/acmqueue.com/htdocs/db/db.php on line 88 ;-)
Fatal error: Call to undefined function: message_die in
Mod me troll, if you must, I can't help it.
The next time there's a debate in the government (at any level) as regards Microsoft or their products I'm going to drag this article out and quickly follow with a list of security holes and patches that have cost businesses and consumers untold millions and billions of dollars in lost time and productivity. The syllogism here is that if sloppy code is to blame for bad security, and Microsoft has bad security then Microsoft must have sloppy coders.
To be fair I've seen some truly horrendous code from other places, including OSS and Free Software, but there's something to be said for MS software as a result of the sloppy-code bad-security angle because they charge so much for it. So much for the old adage You Get What You Pay For. With most Microsoft products you actually get considerably less.
I have to browse the web on a non-developer computer because I get code errors asking if I want to debug on almost every page. I can't believe that so many well known pages allow so many problems in their code...
Which is now /.'ed you would know the author was arguing the point against the hardware people putting buffer overflow checks in hardware for essentially a software design problem.
He was saying that warnings, etc. need to require the programmer to fix errored code (ie, gets() vs fgets()). Like code optimization, security needs to be a low level function of a runtime/compiler.
It is a different take on an old problem. If you don't like it simply don't read it. However, since you waste time posting redundant posts about redundant articles I figured it was right up your alley.
I always suspected that buffer-overflowing, a possible security threat, is the result of a backdoor by design. That is not to say that binary-correctable!-code is a bad thing, but I wonder if Ritchie realized the many different ways his wonderful Pandora box will be used.
It would have been pretty impressive if Java on the web had taken off the way sun envisioned. Flash was pretty new when ActiveX was announced, and it mostly compared to java, in that you could do 'anything' (which unlike java, let you overwrite the hard drive with zeros if the coder wanted).
:P
Honestly, I can't imagine what Microsoft was thinking with that one. ActiveX is used mostly these days as 1) a simpler way to install plugins, or 2) to infect people's machines with spy ware.
Java applets, on the other hand, seem to be limited to interactive scientific demos, these days
autopr0n is like, down and stuff.
Uberhacker.Com
Depending on how skeptical you are today, you might think:
Really bad/inexperienced users write insecure code.
Good programmers write good,secure code.
Excellent programmers that work for companies that make a lot of money from support and updates write insecure code that is easy to fix.
Slashdot Syndrome: the sudden, extreme urge to correct someone in order to validate one's self.
I don't agree. Yes, if programmers wrote perfect code, there would not be vulnerabilities. But programmers are people, and people make mistakes. This is a given.
For the solution, I think we must look not to the programmers, not to the languages per se, but to their standard libraries. C's pointer arithmetic and unchecked array bounds allow for a variety of mistakes, but also for great efficiency. It's the standard functions like gets, scanf, sprintf, even printf that make C unsafe. Sure, the programmer can be blamed for writing unsafe code, but if these functions were removed and replaced by safer ones, there would be that many fewer mistakes to make.
Pointer arithmetic is mostly evil and should be avoided. As for bounds checking, I would think that with all the constant propagation modern optimizing compilers do, it would be easy enough to determine which accesses are guaranteed to not go out of bounds, and do bounds checking for the rest. Exceptions help, too. If something goes wrong that the programmer didn't account for, the program stops. In the best case, that means no harm done. In the worst case, the system is DoSed, a situation which is so undesirable from a productivity point of view that it's going to be fixed, whether or not the parties involved care about security.
Comparing a language that follows all the guidelines set out here to one that doesn't (e.g. Java to C) will quickly reveal the truth: there are far fewer vulnerabilities in safer languages than in unsafer languages.
Of course, mentality plays a role, too. With the industry having mainly focused on features and quantity, I am not surprised that software is so insecure, and I think businesses depending on this model are getting what they asked for.
Please correct me if I got my facts wrong.
No.
They have that for some P.E. (Professional Engineer) licenses and I think it's a terrible idea. An engineer can lose his house and or his license because of one little mistake. Current programmers can and should do better but I don't want to lose my life's work because I used a == instead of a != in a for loop in an anti-virus program.
Nobody ever gives all the reasons for fighting a war, just the popular ones. Deal with it! Just because an impact is secondary or peripheral, doesn't mean it isn't part of the justification.
THere are lots of reasons why we are in Iraq, freedom is one of them, national security is another, WMDs are part of that, So is the fact that it was time to finish a 15 year war, and Bush had the political capital to spend getting it done. 12 years ago his father used up his political capital freeing kuwait and had none left to finish the job.
Aprove or not, This was the best time to finish the job.
Food not Bombs is a nice platitude but it breaks down when you notice that the Bombees are usually well fed
"We need to be realistic in recognizing that we're stuck with a set of languages and environments that are not susceptible to a massive change."
This is a huge cop-out. Buffer overflows simply can not happen in Java. The same goes for almost all of the security problems that are turned into exploits these days. Instead of applying patches to compilers and yelling at ignorant developers, how about just switching to a development language and runtime environment (e.g. Java and its Virtual Machine) that simply doesn't allow these kinds of mistakes to be made?
I thought the misspelling was intentional, but rereading the post I think, uh, it wasn't.
autopr0n is like, down and stuff.
Unfortunately, unless someone as big as Microsoft (ha!) or IBM gets behind the message, you're not going to see much come of it.
.NET. Longhorn will be entirely .NET-based.
They have--see C# and
Not everyone has been saying 'bad programmers cause security holes, not languages.' In fact, quite a few people have been saying that choice of programming language can affect things greatly, particularly people with 'safe' programming languages. This is certainly the case with respect to ye olde buffer overflow.
autopr0n is like, down and stuff.
``I'm not sure that was why applets were not a big hit... I'd blame the slow JVM startup time for that one.''
There is that, and there are the various incompatibilities. Microsoft's VM is not going to run your code, unless you specifically write it to work on it. For other code, you'll typically need a fairly recent VM, which means a hefty download if yours is not up to date. Many users are not willing to invest so much time just to see your sucky applet - and most of them are sucky, compared to real native applications.
Please correct me if I got my facts wrong.
Ummm gosh, the only ActiveX applets I ever saw was right after it was released. Heh, I often say Java is dead on the web (though I know it isn't completely) but now ActiveX is entirely dead except for like the applet on Windows Update :-P
You are a Holy Person, sir/madam.
Go find some pr0n and you'll see a lot of activeX thingies trying to install. Lucky me I use Moz.
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
In other news, Blame bad diseases on sloppy sex. Blame 5 on 2 and 3. Blame the retard next door on his mom and dad. Blame engineering excellence on Apple.
Get a room.
Using "managed code" does not "secure" your projects.
It sure helps. Type-safe, garbage-collected code running sandboxed as opposed to native Win32 junk?
Even DirectX has a Managed API now (and apparently offers 95%-99% performance of equivalent native code...we'll see once somebody actually codes a real engine in C#).
Trying covering a mortgage with a 5 digit salary in Silicon Valley, or anywhere else where development boomed in California.
In Pleasanton, a place where many IT companies are based, the average house sold was over 700,000 last month.
Try covering that with anything less than TWO people making a 6 digit salary... This entire nation isn't as cheap as the midwest (or wherever you live where you think 5 digits pays a mortgage with ease).
Maybe he's not trying to "prove" anything but merely state his opinion that Java is annoying and that people hate it.
Not everything has to be a thesis here, y'know. I don't get why people only ever demand proof for an opinion when it's an opinion that goes against the majority.
Java has a cleaner thread model but is not as extendable as C. In Java you find that what you want to extend is either not an abstraction point or somebody arbitrarily specified the final keyword to stroke his ego.
So basically, you will never get rid of C unitl you replace it with something as easy to extend as C.
Define secure.
I can guarantee that a developer and a customer will have two different definitions of secure. And, the cost will be more than the customer will want to pay.
How many customers can write a scope of work, send it off to a developer, and get a proper quote for a project that includes adequate security? How many customers actually remember to ask for security? Or if they do, do they put enough priority on security?
I bet the answer is very few. I know from past experience that most customers take the cheapest bid. The cheapest bid is usually the one that is skipping something, and the easiest thing to skip is security. If the customer didn't ask for it, is the developer responsible? Is Micro$haft reponsible? Nope. Security is not in their project. They want speed. So, there's always a niche for ActiveX. Microsoft knows they can undercut someone's cost because security isn't an issue.
And everyone complains about Microsoft's future security ideas. Well, what do people really want? Security? Or no security?
-- No sig for you!
1. the bad programmer can't fix it, but says they can, tries anyways and makes it worse.
2. the good programmer can't design it, but says they can, tries anyways and makes it ok.
3. the great programmer invents something like the blinking cursor, which makes life better.
3. the expert is on an island living off of the revenue generated by their two great ideas, one was to hire the good and the bad programmer for peanuts, since the economy sucks, and two was score clients using the great programmer's invention of the blinking cursor.
stuff |
The problem with web apps tends to be security design problems, as opposed to security by technical (ie buffer overflows).
For example, not checking for validity of POST data being sent. I can think of several holes I'd found on some webstore software that would allow a user to enter just about any price they wanted for products, because the store software didn't have a sanity check on incoming price fields.
-
Good security is more a matter of developer foresight than anything else. Almost all of the security flaws known to date hinge on two factors:
The first point applies to a lot of Microsoft software; the second, to a lot of software across the board. The fact that a sysadmin blames compromises on easily-guessed passwords is no solution at all - yes, the user is at fault, but the user wouldn't have chosen a bad password if the system of username/password wasn't broken in the first place. It seems that sysadmins and developers alike forget that ordinary people have to remember things far more important than the dozen or so username/password combinations that it takes to live in today's society...
The society for a thought-free internet welcomes you.
I don't understand why people hate Java so much...
public class SomeCode { public static void main(String[] args) { Buffer.overflow(new Rootkit("31337 3y3 0wN j00z")); } }Bugs should not result in security issues.
I repeat: Bugs should not result in security issues!
A properly designed application will have multiple layers of error detection and security checking. As you write your software, abstract things like security checks and database access into an API, and then do insane amounts of input validation behind that API!
In my home turf language, PHP, one of the biggest common problems in applications is the dreaded SQL-Insertion bug.
The pat, standard answer is to validate-validate-validate!
But, I'm human. I *WILL* make mistakes. It's only a question of when, not if.
Ask yourself: How can I structure my application so that mistakes in this regard do not result in an immediate, full compromise?
I bury database access behind an API that forces me to identify the data being passed to the database, and then trap errors from the database so it doesn't show anything to the web client.
Example:
<?
$sql="INSERT INTO logindata (login, password) VALUES ('[login]', '[password]')";
$todb=array('login'=>$login, 'password'=>$password);
if (!$DB->SafeQuery($sql, $todb))
Error($DB->Error());
?>
What happened here? The SQL statement does not contain any data - instead I'm passing a template for the query, and the data array to parse into the query. The function SafeQuery() does a pattern match to get the names of the fields (in the square brackets) and then does the requisite addslashes(), as well as checking the number of fields to ensure that everything matches up, before actually dumping this statement over to the database.
Errors get trapped within the object, and are accessed through function Error(). This prevents any sensitive information being sent to the browser, and the global Error() function simply displays an "Sorry but an error occured" webpage while logging the text of the error message, and quits.
Now, none of this negates the need to do input validation - but this makes a very bad threat for PHP application all but disappear!
As you develop your applications, structure them as much as possible such that bugs and errors do not result in security breaches.
Use constraints and triggers in your databases to kick out data that can't be demonstrated as good. Use APIs and functions to interface with areas (such as the shell/CGI interface) so that common security mistakes (such as not escaping a shell argument) simply can't happen.
Repeat after me: Bugs should not result in security issues!
I have no problem with your religion until you decide it's reason to deprive others of the truth.
This is exactly what those of us in the trenches coding have been saying for many years. The current abysmal state of poor software performance seems directly correlated to the race to the bottom in 'cutting' develoment cost. The solution to producing secure reliable code is to hire experienced competent programmers who understand security issues, and have a vested and sincere interest in producing reliable secure code. This generally means a long term relationship and with and understanding of the clients's needs and business perspectives, as well as the technical competence and willingness to put forth the efffort required to produce quality code. This is necessarily the oppossite of the current trend towards going with the lowest bidder, outsourcing, H1-B's, and throwing large numbers of low skilled developers at a project rather than using a small group of highly skilled developers. Fortunatley for me however my current client regognizes this and only retains a couple of long term highly skilled developers, they do have a number of very nice, secure and relaible applications to show for this, absent the usual bloated development team. This however may be the exception in the industry. Hopefully the corporate types will eventually figure out that throwing large numbers of low skilled developers at a project will not produce relaible secure code. This issue been well documented obstensibly in works such as 'Mythical Man Month" and "The Pragmatic Programmer" however it seems most corporate manager types have yet to acquire this wisdom. Mark
``10 out of 10 Terrorists agree - Anybody but Bush in 2004''
Also read this.
I don't agree with your sig though - without an enemy they actually have a good reason to fight, terrorists would lose a lot of the support they are getting. They are only so powerful, because many agree with their cause.
Please correct me if I got my facts wrong.
Possibly, yes, but still doesn't necessarily mean it was a good idea.
You are not the customer.
The problem is that QA and development of good specifications prior to a project have a huge impact on the quality of the product that results. Having said that, QA and specifications are never seen directly by the outside world.
Most programmers I know WANT to write good code but have the odds stacked against them. They aren't given the time and resources to do the job well. When it's crunch time, security and quality are the first things to go because they are less likely to get canned over a bug than over a completely missing feature.
This sig has been temporarily disconnected or is no longer in service
The first image conjured up by "sloppy" is someone using sprintf in production code (much buffer overrun potential), raw pointers unnecessarily, ad-hoc string manipulation code, and so on. But it's much deeper than that.
Consider something as simple as BMP file format decoder. Writing a decoder is easy. It takes about 30 minutes tops to write one for a subset of the format. But writing a safe version is much more difficult. First, you have to validate all fields. Easy enough. Then you have to handle attempts to crash an application by passing in really huge values, like 10,000,000 pixels in each dimension. That's a bit trickier, because you have to figure out what you should allow and what you shouldn't. Then you have to deal with intentionally malformed images, where the RLE information doesn't add up to the total image size. Depending on how the code is written, this can cause you to chew through memory past the end of the image. To fix this, you have to put some checks into your inner decoding loop. The temptation to avoid doing this is strong, especially among "performance" oriented coders.
So, yes, you can blame this on poorly written code. But had this been written in a checked language, like Lisp or Python or any similarly safe language, then some of the problems go away immediately. Not all of them but some.
Gödel notwithstanding, Slashdot itself is proof that humans will use *any* language to say stupid things about *anything*. People will even code Java sandbox VMs which crash the OS when processing harmless JPGs. Or moderate informative posts as Trolls. We are unstoppable!
--
make install -not war
It isn't the coders.
I believe it is management's fault for insisting on designs that are unsecure (like ActiveX).
You can have coders who KNOW the correct way.
You can give them tools that help them secure their code.
But those only work if management focuses on secure code instead of "user friendly" features.
And management will only focus on security when the buyers focus on security.
I think we're seeing that now. More people are accepting that Linux is more secure than Windows, so Microsoft has to start focusing on security in an attempt to narrow that perception.
http://www.google.com/search?q=.net+undocumented+A PI
[Fuck Beta]
o0t!
His point is that: why doesn't the compiler/linker/environment help find the errors that programmers make?
He questions why gcc only issues warnings in cases where the generated code can't possibly be right. He goes a little too far by suggesting that we should just plug a GC wrapper into malloc/free (this changes the memory footprint of the program) but his ideas are sound.
Very few programmers have been railing about the inherent danger of the programming environment, and the total lack of help from the compiler. Of course *I* was one of them:
http://bstring.sf.net/
(The bsafe module overrides the most unsafe string function calls, thus forcing the developer to use the safe alternatives.)
http://www.pobox.com/~qed/userInput.html
(A way of using strong typing as a mechanism for duplicating the functionality of "tainting".)
I'm amazed that someone hasn't come up with the idea yet of making malloc() and free() stub-calls into a generic garbage-collected memory allocator and doing away with C memory management altogether.
My gawd, I have writen these kind of systems MANY times when do C and C++. I don't trust this guys skill at all, this is a COMMON work around. I have worked for 3 companies and they have had these kind of things in thier own libraries. Who is this guy?
Come the revolution, the Bourgeois, Capitalistic, "A PARKING STICKER HOLDERS", will be first against the wall!
You can get info about these problems by searching for "java" at cert.org. The most recent one I found was patched last month.
I'm a VB 6, ASP, and VB .NET developer and to put it from my viewpoint. I really don't think has anything to do with the language, compiler, or development environment; but more to do with everything else.
On an average day I deal with patching of our IIS web servers, Administrate 2 MS-SQL servers. In addition to the ENTIRE software development life cycle: from Analysis to maintenance. All the while dealing with 4 to 5 major projects.
If I release bad code it's because someone didn't give me ample time to verify/think about what I'm writing. The people who tend to cause these errors also tend to cause this other problems:
So, do I believe that different languages are inherently better for security? No, but I do believe that some programmers are inherently better for security.
"640 K ought to be enough for anybody." -- Bill Gates, 1981
..and there he said it was (paraphrasing here) common for programmers to sorta ignore error flags and just code out the warnings about memory leaks and arcane whatnot like that, like that made the problem "fixed". No warnings-no problems! On to the next project.....
probably more stuff too, that's all I read though.....
Not a coder here, so I have *no* idea if this is common or not, or true or not, but I *have* noticed on slashdot NO ONE writes bad code,or has written bad code, or thought about bad code, and *everyone* has personally corrected every other coder they ever met on their code, and no one has ever had a boss who knew what he was doing or could read so much as a grocery list without speaking the big words out loud, and only the *other guys* someplace else write bad code, and they always use the wrong language and editor to boot, like on bizarro dotslash forum or something. It's ALL "their" fault that there's ANY of this alleged "bad code" that causes buffer overflows and like acne and flat tires and girls who say no.. Them dang guys "over there", buncha no-good slackers....let's hang 'em!
Tha author is right, and his ideas while not exactly news are good enough to be remarcable.
.. good.
1-Modify standard C/C++ libraries internals -- good.
2-Create 'hardenning' post-executables
3-Improve tools.. good.
But I don't agree on:
1-Nonexecutable hardware flag page is not innecesary, merging data and stack has been always (+20 years) a WRONG idea. Data should not be allowed to be executed without explicit permsission, if we have page faults it's not so extrange to have execution faults.
2-The author seems to ignore or undervalueate moderns unix IDE's as Kdevelop.
What's in a sig?
I think one way to sum it up is to say that errors occur when you force the progammer to think about what the computer should do, instead of what they want done. Why should the programmer have to think about memory allocation, garbage collection, pointers, etc?
Still someone has to do it. Every new device out there needs drivers, bios, etc and when you write those things. The operating system has to deal with mouse input, interrupts, and everything else.
With all the talk of pointers and memory access, I'm surprised that he didn't mention the newer processors and their ability to mark certain portions of memory as execute or non-execute. It won't fix buggy programming, but it would stop those bug leaks from causing a buffer exploit if used correctly. Still it was an interesting read if something of a rant.
First of all, it's hard to argue that any other area in the country has more tech involvement than the bay area. Next it's hard to match the niceties of the location. Winter low of barely below 60 degrees is nice. Then you add in culture, and on top of that all within 30 points of a central point you have San Francisco, Berkeley, Oakland, and development employment area's (like pleasanton, etc).
I'm not complaining about the costs, but I am saying that yes, you MUST make more here to make up for the more expensive living costs. Anybody who thinks that making 6 digits anywhere in the country guarantees an easy mortgage payment is a fool (as the AC displayed in his response about California being "shitty"). And it's not just California, check out Boston or NYC. There are tons of places in this country where the luxury and lifestyles of the location drive up costs.
And by the way, supply and demand aren't broken, supply and demand are what is MAKING these houses cost so much. So many wealthy people want to live here it drives up the cost. Supply and demand is broken in places that have rent ceilings (which cause housing shortages).
Everyone who lives in the midwest should be thankful of the expensive california area's. The fact that everyone here makes more, means that everyone here pays a greater ratio of federal taxes. Without California federal taxes in the entire nation would have to be significantly higher.
And lastly before you assume that I'm an uneducated California dolt, I grew up 18 years in Ohio, have spent 3 years in Indiana going to school, and will return to Indiana from my summer internship this fall. I understand perfectly the economics of both California and the midwest. I'll take California's in a second. But on the same note, when somebody says that 6 digits is enough to pay any mortgage easily, it just shows their ignorance to our nation IMO.
Lets see you write a graphics intensive 3D package that needs to render
_allot_ of polygons in real time in Java. Something like a 3D Data viewer in
OpenGL. Everybody moving to the "safe" languages won't work.
#1: Difficulty: It is harder to write, although having an inherently secure language such as Java or Ada helps. You not only have to think about your algorithm performing correctly, you have have a "hacker's eye" to make sure it cannot be used to compromise the O/S.
#2: Performance: (This is a biggie) Checking parameters and disallowing certain programming techniques that could be misused to compromise the underlying system will have a performance impact. It also makes for fatter code, if you ever tried to decompile Ada. The performance loss may or may not be significant, depending on the algorithm. But for something like direct X that provides a thin software layer for high performance graphics, I suspect the performance hit would be unacceptable. This is probably true for other high performance apps as well. That is why 99.99% of all software comes with a "caveat emptor" EULA. (Imagine if they built airplanes, cars, and buildings like that?)
Safety and life critical application will of course always be coded using "tinfoil hat" secure languages and operating systems. They also cost 100x as much to do the same job, and require more powerful hardware to do the job.
#3: Complexity: The more complex a given system is, the harder it is to secure it. The more complex the system, the more places for flaws to hide.
My rights don't need management.
Software has millions of lines of code, and each can contain an error. Trying to get 100% working isn't possible! 99.99% is good enough.
...yet the errata on the hardware often fits in a single page. It's NOT simple to reproduce.
IMO, this is the mindset of the typical programmer. Now consider the hardware side:
42M transistors in a P4 (the earlier ones, this number has gone up)
135M transistors in a Radeon 8500
Atleast a few million in the chipsets.
Depending on how much RAM you have, could be billions of transistors there.
You don't know what the user is going to do!
So? Take your USB port that shines from the front of the PC. Nice and inviting, provides a few W of power and a pair of data lines... now jam your finger in it. Can't do it, can you? What happens if you short out the power lines? There's a fuse on the motherboard. What happens if a device isn't wired up correctly? The OS doesn't even get a chance to see it.
Why do I think hardware has less errors than software? Because hardware errors are expensive. Consider the millions Intel went through on the MTH problem. They recalled motherboards and replaced them with different ones, having to give away RAM in the process. Now consider MS on the (one of the?) RPC vulnerabilities, they put up a patch. That's it. Job's done.
Software engineers think of themselves too much like artists, and not enough like scientists. Don't do something in a way that looks good because it looks good. Do something in a way that works well because you need it to work well.
If you think education is expensive, you should try ignorance -- Derek Bok, president of Harvard
Here is my general view of the "secure programming" world. It goes out to all developers.
Know your tools. Choose them wisely -
Low level languages are not the problem; they are the most widely understood. Security is a process not a language. When your code inherits features and functionality that you did not intend, bad things can happen. Sure, we may not have buffer overflows, but if your RPC function allows me to execute any code that I want without overflowing buffers, who cares? Also, with these super portable "sand box" languages, I get to find one hole and exploit it everywhere. If you think Java is the answer, please tell me what language you think Java was written in? Also, please read "Reflections on Trusting Trust" by Ken Thompson.
Seeing the big picture -
Peer review is part of the security process; your attackers are becoming very skilled at finding exploitable software bugs using automated tools to help them. Everyone in the development process needs to know the type of application they are developing and the sensitivity levels of the information they are protecting.
Rule of Simplicity -
Design for simplicity; add complexity only where you must. Default to Deny, compartmentalization of code is good for more than just limiting security bugs.
Sweat the small stuff -
Just because certain attack vectors are obscure does not negate their effectiveness; writing good clean code is safer and more sane than allowing a program to "protect" bad coding practices at execution time. We have seen many examples of how this other type of protection fails.
Don't use your customers as your Q/A staff -
The Microsoft Software Release cycle is destroying security from the users and programmers perspective; it causes users to not want to upgrade, and it causes programmers to not want to fix security problems.
Don't build a $100,000 fence for a $1,000 horse -
All data is not created equal, don't treat it as such. Let the protection be commensurate with the asset.
Audit trails -
Trust with accountability. Every significant access, whether denied or permitted must maintain an audit trail.
Since when is security "just another feature". I think we're already aiming too low. Security is a lot closer to the first feature you should get right than anything else. Putting security as "just a feature" means if you have several features, and you have to choose, you can pick features, and not pick security. Isn't that much where we are now? Except that the IDE developers he mentions aren't involved? Getting the IDE environment developers to focus a bit more on security is certainly not a deterrent to security itself, but it means security-as-a-feature-of-ides will only work if:
1) you can't turn off the ide's security features
2) you can turn them off, but they are zero-cost, you never turn them off.
1) Could work if it didn't hamper backwards compatibility, which it will. Notice how much more code with bugs is tied to old ways of doing things, as opposed to redesigns. (Yes you can introduce new bugs with a new approach, but if you're using a new approach, you aren't likely to misunderstand the approach as much as someone else's old approach, when he isn't there to explain anymore)
2) Is laughable, there is no perpetual movement machine, there are no environments where adding checking and validation to all data structures and exchanges will be a zero sum, and count on the unvalidated, unchecked structures to be the sources of bugs. Will developers check as much if they feel it's the compiler's job? How many will understand enough about the compiler to back-check the compiler, and verify that whatever isn't self-validating is being validated?
Making security a less painful option for developers is a good idea, and getting the people who make our tools consider it as important to write tools that write secure code as we consider it important to write secure code is a good step.
But, when was the last time you pushed back a release date a week for security testing? I don't mean you know there's a bug, and you need time to write a fix. I mean you know of a bug, you have the fix, but you wrote it "Today" as in the day you were supposed to hand in the released software. Would whoever you released it to understand?
Of course they should, but they don't, and we don't educate them about it either. Do we really care that much about security? I have my doubts.
However, it's not programmer laziness that prompted the switch to ActiveX -- it was that Microsoft never included a JVM beyond 1.0. And this was for monopolistic reasons. While quality code may be necessary for secure code, the same can be said for a non-monopolistic market (and of course neither is sufficient by itself).
It's just another example of how academic researchers are out of touch with reality -- in this case, it's so extreme, that the researcher ignored The Microsoft Problem.
Microsoft have a revenue stream based on bad security - Its all just revenue based management and nothing more.
I worked, at CenterLine, on a follow-on for CodeCenter that used compiled-in checks to get similar checking at a higher speed than the intepreter. It was a wonderful accomplishment, but it was still vastly slower than a good Java or Modula-3 implementation. Use a safe language, end of stupid security bugs, and you can spend more time worrying about the subtle ones.
One more thing to note, if you take the draconian view that warnings are for wimps: I found one real program, in all that I tried as tests, that did not generate a single warning during its execution, and that was gzip. One of the emacses was our error-filtering test case; running to the "dump" step, it generated over one million diagnostics, which we managed to automatically filter down to one thousand.
I really have to wonder about the author's background. He claims to care about this, yet has apparently never used Java outside of a browser, nor played with the BDW-GC for as a leak backstop. I sure do wish the ACM editors were a little more clueful.
Starting with the last - He praises M$ development environments. OK, what was the last major Bug that even made the Drudge Report. An IIS and IE combo - why are IIS sites defaced more since it is the minority and even CERT is saying to switch browsers (how do I load Firefox or Apache into Visual.net?).
He complains about C malloc/free (ever heard of electric fence?). C++ (wasn't OOP the magic bullet?) gave us new and delete and some garbage collection and more memory leaks (but he says we shouldn't use Java which actually gets the conceptual model right). Oh, and every makefile I have has -Wall, and running them produces no warnings (at least when I'm through changing things algorithmically). And I'll have to look again for a good opensource lint. I used commercial products for a while.
Since I'm often doing embedded, I have to be careful and have space and timing requirements (and in many cases NO debug facilities) few others have to deal with.
The article is probably worth reading, but won't be very helpful. A lot of people don't understand the art of programming even if they make their living that way. The people doing the hiring either want the buzzword checklist, or don't care if the result is brittle (at least not when the project starts).
His solution is more "magic bullets". Everyone I know (even many I would not let write a simple sort routine) was horrified by ActiveX (v.s. Java). How do you make that secure? You can't.
A security shell inserter like pixie? Maybe it would be a source of exploits (basically it is a manual virus - if you can alter an EXE to add a security shell...). And an IDE can be a great tool (Emacs works for me) but also can make one lazy - I assume IE and IIS with all their holes are developed on the same praised IDEs.
There is an art to programming and it often takes 5 years and is a way of thinking, not a "method". I do Java and C++, but I don't do them differently than I do C. But much education (and investment) seems to be toward finding a product or method to replace process.
As often has been said: Security is a process not a product.
My own saying: I don't write complex programs, I simplify and reduce complex tasks into simple programs.
Good Cheap Quick, pick 2.
-- the problem is the OS security model. If I cannot run a program and not know, with a guaranteed certainty, what it can and cannot do to the rest of my system, then it's a matter of trust and faith, which is where it all goes downhill.
In another few decades, the quaint notion of all security capabilities being tied up with a user will be gone. Thought will actually have to be had for each and every program / module: what *exactly* does this need to be able to do?
And, since security and reliability go hand in hand, we'll actually be getting somewhere in this IT world!
Mark
Um...I don't think it's possible to build an X86 OS to operate from within a VM. Even .NET.
.NET. Hate them if you want, but don't say they haven't tried because they have.
Why? Or are you talking about the kernel? Obviously the kernel won't be running in a VM, but the rest of the operating system will. Remember, the operating system is more than just the kernel. explorer.exe is already running as managed code in the current Longhorn builds.
Microsoft isn't shouting that shoddy programming practices cause security flaws...for them, that would be a really bad PR move.
You're lying out of your teeth. They've been very vocal about this, even if you haven't read about it on Slashdot. They're completely replacing Win32 with
More like bad mangement:
Poor requirements, with new features getting added too near relese.
Well it looks like it works fine so lets release it.
Make sure the product performs well, don't bother with the checking everything(not that you can't have performance and security)
Poor recruiting by HR.
thank God the internet isn't a human right.
And with fewer vulnerabilities, you can pay more attention to the types of vulnerabilities that remain.
Remember, what you are making here is a conditional statement of the form "B if A". If A is false, nothing is known about the value of B. Sadly, many people use the silver bullets of better tools and instead of concentrating on security where the effort is actually needed, they behave as if the tool does it all. Of course, C# code written by an expert who does take security seriously will be at least as good as either and probably better. Now if we can put it on an OS that doesn't crash.
C code written by an expert who knows the vulnerabilities of C and uses other tools to check it such as lint is going to be more secure than C# code written by an inexperienced programmer who never gave any thought to security. It will have different kinds of vulnerabilities.
On the topic where memory management related security issue is blamed on reluctance to switch away from C...
This is not true. Cyclone does exactly that, and more. Cyclone is a dialect of C. In fact, a lot of C code can be ported to Cyclone with little to no modification. It has garbage collection for stub malloc/free code, and optionally region memory management where you can dictate when some collection of objects are deallocated all at once.
I once had a signature.
I've been programming for 20 years now, and I have to say that I still make mistakes. Sometimes I will create a proof of concept code, and when it works, implement it into an app, but forget to properly exception handle, or any not spot a possible buffer overflow code segment.
I won't get into which language is best/most secure/holds my hands the most - it's up to us to code, and being human we make mistakes, no matter what language is used.
One of the problems is the deadline pressure in closed source shops. In the rush to market, it is very easy to cut corners and leave holes. That is the project managers error, not taking proper QC time into account.
Without the open peer revue, code like
char inputbuffer[100];
sscanf( inputbuffer, "%s" );
may make it into the production code. With open source, I can almost guarantee I'll get an email like:
Hey moron! You left a hole I could drive a mack truck through in some_code.c at line 57.
The problem is that in many shops, programmers are not allowed to write good code, only fast production code.
A good "performance oriented" coder would know better than to choose an algorithm whose safety depended on doing a test in an inner loop. He's probably used a series of bitmasks, AND's, and shifts to ensure that even if the values were out of range that they didn't cause problems.
As an assembly programmer, I've learned two very helpful techniques to avoid overwriting memory:
Performance programming is not simply leaving out vital checks. Rather, it is designing algorithms in such a manner that the checks are unnecessary, or performed at a level where they are easily handled. Even a good C++ programmer wouldn't think of starting to render a BMP before having validated all of his fields.
The society for a thought-free internet welcomes you.
After more than 20 years of C programming, I must still be too stupid to avoid pointer errors. So, stupid people like myself can use languages other than C, and positively brilliant people like him can stick with C. But who the hell is writing all the applications, then, that keep crashing and that keep getting broken into?
... who did it! Naughty naughty.. but hey, I feel bad now. I mean, now you got the lynchmob heading your way and all, I feel sorta sorry fer ya... tell ya whut... just betwixt you n me... I got a buddy, a good frined, well, he's a bigshot over in boogorrillaville, he's their vice minister of procurement. WELL, he sorta got himself into a fix. And it's all because of BAD CODE YOU WROTE, so you can do pennace now and fix this up. He found out that at the end of last quarter that something happned to the accounts from that buggy software they got, and it seems that 83 million drachmadinars seem to be outstanding and left in the budget unspent. whoops! It was earmarked for genetic research on advanced all wheel drive camels, but yu know those eggheads, couldn't find their trousers with a GPS and a map.. anyway,they diodn't spend it and seemed to have forgotten about it,and if he doesn't get rid of all this money and leave not a trace of it, his patooty is grass, and the project will get cancelled, and his nephew runs the largest camel herd breeding operation over there. SO, he approached me using his phreaked cell phone he snagged from a tourist, knowing I am a famous internet browser user so I know all about coding and and money laundering and banking and such like, and asked for my help. Lucky me through my skills at typed "stress and duress" internet posting I was able to flush you out and make you see the error of your ways. No harm nor foul, you can make amends and we will help you get the funds you need to staert your own ethical softweare company, maybe..say...25% of the take? Sounds good? Good! so this is what you do. First, we need a totally obscure bank account to transfer the funds through, after first establishing a shell corporation in the turks and caicos. I can't use my name or account to do this because his government monitors his email so they know to watch me close. And ,well, I got this hassle with interpol and all, but that'll work out. We will first have you transfer your small account in the US over to the new dummy corporations account, just to get it setup and legit looking, then......
whoops, this is in public! We better discuss this someplace else. To continue, send me an email at my secure addy islandking@margarita.td.con
SUCKS being forced to be bogus just to hang on to a job. I been there, I can relate. I had to quit a few jobs over bad management. One time it was a contractor, I was watching him build, what he was telling me to do, it was AWFUL skanky construction. I lasted a coupla days and just never went back. I mean, this guy was cheap, and just didn't care. Selling these big expensive houses, he'd go "all you need is ONE nail in that stud", stuff like that, were normally you would shoot two. Not caring about plumb. Just skanky stuff. Say the saw guy cut a piece short. Normally you'd set it aside, save it to cut shorter pieces out of it. Not this boss though, if you could hold it in place and a shot nail would bridge the gap, it passed.
ya, I seen stuff like that. Sucks. Hard and expensive to start your own business, hard to know much about the company and boss you are going to work for until after you get hired and start work. In the mean time, that "bill" jerk keeps showing up in the mailbox no matter what else is going on.Sucks.
Well, I hope you got a better place to code at now.
We have already GONE there. Java, .NET, fancy smancy libraries for C and C++ all exist and are all far far safer than the old stuff lieing around. Microsoft has taken notice of the security trends are and introducing many backwards compatability breaking changes into XP SP2. When Microsoft *knowingly* breaks backwards compatability, you know they mean business (see this article, even tho I agree with the "MSDN Camp": http://www.joelonsoftware.com/articles/APIWar.html ). Even tho everyone on /. hates them, you can't deny that when Microsoft starts a "bet the company" style trend, that the rest of the tech world doesn't play along.
http://brandonbloom.name
You're right! We'll have to do something about that: this calls for a shell script!There, everybody run that for a few hours(months?!?) and Java will have finally caught up with the rest of us.
Oh, and Please use fewer 'junk' characters. =P
And how about code that exploits those unsafe functions? One example is 32 bit flat real mode used by Ultima 7. The other is a trick that uses MapLS/UnmapLS to modify the LDT base address so it can create it's own threads in the virtual memory manager bypassing the kernel (Bleem, works on Windows 9x only). Some apps may rely on the ability to (locally) exploit a buffer overrun to bypass the slow dynamic linker. There are many other cases of apps exploiting bugs to increase performace, that is one of the reasons the wine project has had so much trouble.
ActiveX was never meant to be secure, nor for sandboxing code. It was meant to be the replacement for embedding Excel spreadsheets into Word docs. Then they added stuff to try to make it into a Netscape killer by bribing developers to use it as a feature on their websites. ActiveX is a kludge, it keeps getting new warts and features to make it seem New and Improved!
How do you mark an ActiveX control safe for scripting? There is a magic value you place in the registry. Yep, that's right, the author of the control is trusted to claim that it is safe. It is as safe as asking folks getting on a plane if they have any guns. How many airlines settle for merely asking their customers vs how many run their customers through metal detectors?
Blame Sloppy Programming on bad security in programming tools.
How's a coffee cup warmer?a ccessory/ accessory%20series-USB%20Coffer%20Warmer.htm
http://www.sunbeamtech.com/new/products/
Motherboard didn't always have a standard USB pinout. (if they do now). Think hardware plans don't go through the same time restraints? If you do, lay off the crack. Consider that EVERY YEAR new videocard chipsets come out, and half way through usually get a revamp. Think you can design and test an all new design in a single year? Get that nice fat 14 layer board right the first time? Hardware has the advantage of they make STANDARDS for interfaces (Hear that MS? An agreed upon industry standard!). And transfer to production isn't just making disks, you have to setup numerous processes and accumulate the materials used. That stuff doesn't come at a short time frame.
Hardware can do it, why can't software?
If you think education is expensive, you should try ignorance -- Derek Bok, president of Harvard
The quality of code written by windows developers using Visual Tools and what have you
is actually quite pathetic to say the least (I am talking from real life 50K+ source code audits).
When the exe crashes the great windows engineer, just right clicks on the exe and changes the stack size to 1Mb. The manager sees the demo working and is gratified with the progress.
The author's whatever experience takes a beating, if he hasn't seen the situation above and which is a garden variety bad software engineering using visual tools.
There are plenty of '.TAB' technology coders sitting out there using visual tools, who
keep searching for 'the method' by scrolling through the popup pane. What productivity
or insight is achieved by that ?
If the visual tools were so great and so effective and really 21st century, most of the windows supportive security companies (including TruSecure) would not have existed!
The author's assertion that open source tools have hurt us more than helped us, is neither factually correct nor logically defensible. If he has learnt a bit or two of programming and
practices, it is primarily because of the open source tools.
Sure, open source tools are not meant to fund your next great car or your divorce suit!
They exist with a purpose and that is to write great software by the real software artisans.
It is fashionable to talk of 'garbage collection' in almost any forum, by authors of 0 - n years of experience. This article is no different.
'garbage collection' exists with a specific purpose. However, it still cannot address your morning nature's call. So much for
making sweeping statements about applicability of garbage collection, with 15 years of experience.
Perhaps ACM Queue should ponder that publishing articles which are little more than mental regurgitations, will neither help the cause nor
the subscription numbers. The readers will continue to be in the queue for enlightenment!
For the record
int i;
if( a )
i = 0;
else
i = 1;
Will NOT generate a warning under gcc 3.3 (-Wall with optimisation). This will:
int i;
if( a )
i = 0;
else if( b )
i = 1;
Compilers can be smarter and help us poor mortals along. There is code that will give warnings that are not strictly correct (other logic ensure that the unitialised variable is never referenced like a boolean guard value) but it is simple enough to code in a reasonable default in case some idiot does a poor change later on.
Ignoring the warning on the other hand will lead to program crashes in obscure ways. It works on Solaris and Windows but not on Linux. I am currently working through OpenOffice.org removing unitialised variables, costs a little effort and potentially a good pay back on my time in program stability. It may not correct all the bugs but it should make the problems repeatable because it starts from a known value.
As a systems programmer, I say "go ahead and keep on living in that fantasy world and then pay me the big bucks when you run into problems".
Java is such a farce. Java has the "great elbow" in every performance curve I've ever seen. Once the garbage collection kicks in just watch preformance drop through the floor. I've never seen it do anything less even in the latest JDKs. Whenever I tell them "buy more machines" my management gets pissed off because GC is suppose to be as fast as non-GC code. A GC machine is only as fast as a non-GC machine when its under a partial load, ideally around 50%. We have non-GC production machines running at near capacity (100% VM and 80% CPU) with uptimes of six-months or longer. Management wants to know why they can't load Java machines up to capacity the way their other servers not running Java are loaded.
Java is NOT a systems programming language and GC is not for systems programs, period.
And don't get me going on memory leaks. We've been running our JVM logging on "verbose" logging mode for three years running because developers continually allocate buffers for PDFs and other large files in ways that defeat garbage collection. They inerrantly allocate memory faster than GC can collect. THIS HAPPENS every production release. Tell a developer they can be sloppy and they will.
Millions of lines of legacy code?
His solution of turning warnings into errors is a pipe dream only realizable in world where companies are going to discard existing software.
As a consultant doing contract work I've seen what happens when large corporations try to use lint, splint or other tools on new code that compiles against old code. It's not pretty.
Security, as it goes, needs to be applied to legacy code being compiled into new code. He completely fails to mention legacy code and the cost of bringing it up to date.
Who's going to pay for it?
White is colored white, black is colored black, chartreuse is colored chartreuse...
I kid you not. Keeping the programs as simple as possible combined with input validation of all user input would solve a lot of problems involved with writing 'secure programs'.
This'll end up on the fourth screen of threads, but it's worth reading for those who find it. It's over seven years old, but essentially everything in it holds true today. (worth reading on various lists I don't have it bookmarked - I knew where it was.
"They Write The Right Stuff". I'm not even going to provide a summary of everything which is listed in the article. There are a lot of good lessons in well organized, well thought out explanations as to why the software doesn't shut down but how few errors are found.
There is a difference between a shuttle crew and standard users. 1) A shuttle crew is a smaller user body. 2) They're more likely to follow instructions ala "what happens if I hit this button?"
I've never sent a note to the author, but I think it would be a book as important as Writing Solid Code (is that the right one? (I've been up a little too long without a syringe.)
You can have a userfriendly program which is also designed, coded and reviewed with security in mind, you know. Or you can have a totally unusable mess which also is buggy and exploitable.
A polar bear is a cartesian bear after a coordinate transform.
I'm not normally a spelling or grammar nazi, but lose spelt l-o-o-s-e irritates the fuck out of me. It's a common, simple, four letter word. This is not like misspelling "psilocybin" or something. I would expect a five year old child to know the difference between "lose" and "loose".
And before some whining bitch bleats about language evolving, this part of it hasn't evolved. Check in a dictionary - it's wrong. "Loose" is taken. It already means something.
Back before dictionaries you could spell words how you liked, and that was how spelling evolved. Nowadays, you spell like the rest of us, or people will think - rightly or wrongly - that you're an idiot.
Well next year there is a Language revision - with containers. Besides, before you claim there are no Container Libs for Ada you might at least try the simplest Google: http://directory.google.com/Top/Computers/Programm ing/Languages/Ada/Bindings_and_Libraries/
Ada actualy has container libaries which can store polymorfic objects - something neither C++ nor Java can. They can only store pointers to polymorfic abjects.
Martin
As a matter of fact:
:= i + 1;
ISO/IEC 9899 Programing Language C : 538 pages
ISO/IEC 8652 Ada Reference Manual : 560 pages
ISO/IEC 14882 Programing Language C++ : 757 pages
I have got them all. I read them all.
So you are telling me that 22 pages less makes C a slim language compared to Ada?
And I wonder who truely has to many ways to do the same thing:
i = i + 1;
i += 1;
i++;
++i;
In Ada there is only one way:
i
Ada has a lot features - true - but they aren't duplicates. They are all usefull features.
Martin
And the funny thing is that the STL was inspired by an much older library written in Ada.
Because what ready makes the end-user choke is when you store string longer then the allocated space.
S trings
And the end-user is more important then us programers.
Beside, if you allow for Libraries then there is:
Ada.Strings.Fixed_Strings
Ada.Strings.Bounded_
Ada.Strings.Unbounded_Strings
Martin
Look, I know you have problems with comprehension, so I'll take this slowly for you.
Whether you like it or not, opinions can be either based on fact or not and as such can be proven to be true or false. An example:
"I am of the opinion that the world is flat."
Note that while it is an opinion, it is also entirely provable as to truth or falsity. So while you may hold an opinion and demand that nobody scrutinize it because, "Hey, it's just *my* opinion," you're living in a fantasy world.
Opinions can and usually do have an element that can be either proven true or false. Sorry if you don't like it, but that's the way it is. And if your "opinion" is based on falsehood, don't expect anyone to take you seriously.
Sheesh. How this kind of garbage gets modded up as insightful is beyond me.
Funny as you say that you type end faster then }.
:-(.
Have you ever seen a non english keyboard and where they hide the { } there.
On a german keyboard it is 3rd function 7 and 0.
That's 3rd function not just shift
The Problem with C is that the default is unsave and you have to go out of your way to make it save.
There are programming where it is the other way round. Ada for example is often described as the "save language" yet it does have all the "unsave" features as well.
Unchecked_Convertion will convert everything as long as the size is the same.
"for X'Address use Y'Address" will convert even when the size does not fit. And it is faster - no data copied.
Yes you have to type more - but even when most of you never did any Ada you will all know what "for X'Address use Y'Address" means and that it is indeed a nasty hack.
But I give it to the C comunity: Sometimes you need nasty hacks. But do nasty hacks need to be the standart behavior of the language?
The only time a bound need to be checked is when a type is converted. As long as you are within one type no checks are needed since the bound are already garaneed.
With there are some many type convertions that indeed checks would be needed left right and center.
say for example:
auto char X[10] = "123456789";
auto char Y[20] = "1234567890123456789";
x = y;
C's problem is that the arrays y and y are convertet to char* and then assigned. Hence the bounds are lost.
Calling strcpy would make things even worse!
In Ada, Modula-2 and Pascal the arrays are not converted and the compiler will be able to check the bound at compiler time and will isue an error - since X is not large enough to hold the value.
Other example:
typedef char T[10];
f (T X, T Y)
{
strcpy (x, y);
}
Again C converts the arrays into char* and looses the bounds. You can pass to many chars into the function and compiler says nothing:
f ("1234567890123", "123456789012345");
Again in Ada this would not happen. And again no bound check would happen. The compiler knows from the used type that both strings are 10 characters and can be assiged savely.
This is called "design by contract". And with "design by contract" the compiler will be able to optimize away most bound checks. Or even do them at runtime.
There is actualy a language call "SPARC" which will evaluate all contracts at compile time ensuring that no contract will be broken at runtime.
Programming SPARC is hard - but if you do the fly by wire of an Boing 777 any broken contract will meen 600 people drown in the atlantic ocean.
The problem with C is that you can write a contract down:
typedef char T[10];
But the compiler ignores the contract afterwards.
Martin
While it's not a magic bullet, Valgrind can help a lot to find otherwise difficult to spot memory handling errors during code development. And quite easy to use / requires quite little additional effort. In addition to memory use debugging it also offers features such as cache profiling.
Its downside is that with computation/memory intensive programs its overhead can be quite noticeable; don't expect e.g. Mozilla to be a speed demon when run with Valgrind. And oh, it's mostly x86 - only, although an experimental PPC version seems to exist these days as well.
Everyone who makes generalizations should be shot.
You example will be the following in Ada:
:= 5; := 2 * A + 1; .. 10); := 'Z';
.. 10);
.. 10;
.. 10;
:= 5; := 2 * A + 1; := 'Z';
/. forced me to make paragraphs longer then I wanted to
procedure Test
is
A : Integer
B : Integer
X : String (1
begin
X (B)
end Test;
and when you compile that with the gnu compiler collection:
>gcc -x ada -gnatwa -c test.adb
test.adb:3:04: warning: "A" is not modified, could be declared constant
test.adb:4:04: warning: "B" is not modified, could be declared constant
test.adb:7:07: warning: value not in range of subtype of "Standard.Integer" defined at line 5
test.adb:7:07: warning: "Constraint_Error" will be raised at run time
And you are wrong when you think there is no type convertion in your example. You see in a strictly types language
X : String (1
is a shorthand for:
subtype X_Range is Natural range 1
subtype X_String is String (X_Range);
X : X_String;
Now B, beeing an Integer, is converted into the type of X'Range. I can make this clear by exanding the code:
procedure Test
is
subtype X_Range is Natural range 1
subtype X_String is String (X_Range);
A : constant Integer
B : constant Integer
X : X_String;
begin
X (B)
end Test;
if you compile that:
>gcc -x ada -gnatwa -c test.adb
test.adb:10:07: warning: value not in range of type "X_Range" defined at line 3
test.adb:10:07: warning: "Constraint_Error" will be raised at run time
Integer and the range of the X are different types and need to be converted. Most C programmers just don't know how often type are convertet. Try http://www.splint.org and see how often a type is converted in your programs. Of course, strictly typed languages help the programmer avoid type convertions. for excample in a loop:
for I in X'Range loop
No bound checks needed in that loop. I will iterate over every element of X - no more no less.
The usual Ada programmer spends only 1/10 of the time debugging when compared to a C programmer. He does spend a lot more time typing and analysing compiler output - But that is less painfull then debugging.
With Regards
Martin
Sorry for the bad formating:
You are still operating under the delusion that range checks only occur when converting types. They don't, not even in your precious Ada. I don't know Ada much beyond one semester of it back in college, but I do know that it's a computer language, and must therefore run on an actual CPU at some point. And that's enough to tell what's wrong with your claim.
Running on an actual CPU means there's no such thing as a data type that stores numbers from 1 to 10 and is unable to store anything else. Not on a computer made up of binary numbers. a 3 bit number can store from 0 to 7, a 4 bit number from 0 to 15. There cannot be any such thing as a type that stores a number from 1 to 10. What actually exists when you have that type is a larger integer of some sort, maybe an 8-bit integer, maybe a 32 bit integer - maybe even a tiny 4-bit integer, but the point is that there's no such thing as a 3.3219-bit number, and that means the only way to ensure it will never have a number larger than 10 is to check for it at runtime. So you are still doing a lot of bounds checking, only you are doing the checks every time the range variable changes instead of doing it every time the range variable is used in an array reference. You have successfully removed the check from the array reference merely by putting it somewhere else instead, not by actually getting rid of it or it's overhead.
That guarantee that the index variable is in the range of 1..10 didn't come for free without the cpu doing runtime checks. It happened at exactly the same expense as bounds checking the array - it just happened a bit earlier in the process.
Oh, and by the way, I'm sick of you talking about how "C programers" think. I'm a programmer. Period. C is just one of many languages I use.
Don't label something "offtopic" unless you know the topic well enough to tell what's on topic.
Since you have done some Ada I can remind you of one important thing:
:= 12;
:= X_Range'(12);
:= X_Range'(10); := A;
:= A;
.. B loop := Z;
.. 10. Each possible value of I is guaranteed to be a propper subscript for the array
.. B loop := Z;
For every type T there is T'Base. The 'Base type is the type used by a given CPU you where talking about. The type of X_Range'Base was of course Standard.Natural. Standard.Natural'Base is Standart'Integer and that was 32 bit with the give compiler.
If you say:
A : X_Range
Then the the Standart'Integer 12 is converted into X_Range. That will fail. And since it allways fails the compiler will warn you. If you prefer to get a compile time error you could have written:
A : X_Range
Remember: X_Range'(12) means Interpret the literal 12 as X_Range. 12 is not a valid X_Range - the program will not compiler. But since this will only work with literals it is beside the point. But it will alow me to show you an example where there is no bound check at all:
A : X_Range
B : X_Range
In assignment of A line 10 is interpreted as an X_Range. The compiler will check at compile time that it is valid. Now A is a 32 bit number with a guarantee to be in the range of 1 to 10. When assigning to B the compiler will accept the guarantee and not check A again.
This is, of course not interesting. The following is:
procedure F (A : in X_Range)
is
B : X_Range
begin
end F;
A is still guaranteed to be between 1 and 10. No additional check needed when assigning B. And coming back to an Array:
procedure Z (
A : in X_Range;
B : in X_Range;
X : in out X_String)
is
begin
for I in X_Range range A
X (I)
end Z;
No bound check needed here. A and B is guarantee to be in range 1..10. X is guaranteed to have an array element for each position in the range if 1
X. No types converted (A, B and I are 32 bit) no bounds checked (all bounds are guaranteed).
When I first read about Eiffel I was wondering why the contracts are checked outside the function and not inside. At first I considered it an enormous waste.
But then I began tho see that the contract can cascade upwards and only need to checked at the top level of the program.
Of corse there at the top level all bounds do indeed need to be checked. And when you choose your types unwise. i.E: just use the standart types:
procedure Z (
A : in Integer;
B : in Integer;
X : in out String)
is
begin
for I in Natural range A
X (I)
end Z;
will have tons of checks. X is an indefinite and carries two hidden extra parameters X'First and X'Last to make bound checks possible. A and B can be negative but all indices of X must be positive. etc. pp.
It all depends on how wise you choose your contracts if the cascading effect will happen or not.
With Regards
Martin