Re: [SC-L] Interesting article on the adoption of Software Security
Crispin Cowan wrote: However, where ever C made an arbitrary decision (either way is just as good) PL/M went the opposite direction from C, making it very annoying for a C programmer to use. Does that mean it did not make any decision at all? What was the outcome? Michael S Hines wrote: When you've been around for a while, you start to see the same features converge.. UNIX had quotas, we got Quotas with Win XP Server (well earlier, when you include the third party ISVs - as an add on). IBM had Language Environment (LE) before .NET come along. Crispin Cowan wrote: I think .Net borrows most heavily from Java. Java in turn borrows from everyone. The managed code thing in particular leads back to the Pascal P-code interpreter; a kludge to make the Pascal compiler easier to implement and port. The innovation in Java was to take this ugly kludge and market it as a feature :) I'm not sure that it can be blamed on Pascal. Microsoft was shipping Excel for the Mac in the early 80's as P-Code application and has been selling P-Code generating compilers since about the same time. Ever since, MS was strong on P-Code generating compilers. Michael, let me please correct two more things in your comment: 1) there is no such thing as a Windows XP server (probably you refer to Windows 2003 Server) 2) Quotas have been native to Windows 2000 already (lets not discuss quota management now...) cheers Andreas
RE: [SC-L] Interesting article on the adoption of Software Security
Dana Epp wrote...
[...snip...]
For those of us who write kernel mode / ring0 code, what language are
you suggesting we write in? Name a good typesafe language that you have
PRACTICALLY seen to write kernel mode code in. Especially on Windows and
the Linux platform. I am not trying to fuel the argument over which
language is better, it comes down to the right tool for the right job. I
know back in December ljknews suggested PL/I and Ada, but who has
actually seen production code in either Windows or Linux using it?
I suppose it's _possible_ that one might be able to sneak in a bit of
carefully constructed C++ in one of these kernels, but you'd probably
have to be very careful about what you used (e.g., probably most of
STL is out) and in the end, you'd probably have to use
extern C {
...
}
wrappers around most of your stuff so it could interface with the
rest of the kernel.
I thought of doing something like this back in 1990 when working on
device drivers with the Unix System V kernel at Bell Labs, but the
potential problems (several having to do with DTORs IIRC and the binding
issues) seemed to outweigh any potential gain. I thought of also using
C++ as a better (more strongly typed) C, but that too didn't seem
worth it.
Of course, there are some kernels that were implemented in C++; Clouds
comes to mind.
Lets face it. You aren't going to normally see Java or C# in kernel code
(yes I am aware of JavaOS and some guys at Microsoft wanting to write
everything in their kernel via managed code) but its just not going to
happen in practice. C and ASM is the right tool in this area of code.
I'd pretty much agree with this. You seldom even see Java or C# used in
real-time systems (and let's face it, the kernel itself is pretty much
real-time; don't want to be missing an interrupt while doing GC).
Perhaps once the Real-time Specification for Java is approved and
implemented by Sun, this will change, but I don't think that we'll
be seeing many new OSes adopt Java or C# for their kernel code.
(However, I think this also has to do in part with the fact that most
OS/kernel developers are not experts in OO...just my opinion.)
[...snip...]
Cripin is right; new code SHOULD be written in a type safe language
unless there is a very strong reason to do otherwise. The reality is
that many developers don't know when that right time is. And resulting
is poor choice in tools, languages and structure.
I think, in a large part, that's because your average developer knows
only one or maybe two programming languages. And if they know more,
they only know languages from a single paradigm (e.g., OO, logic programming,
functional programming, procedural, etc.). Because of this, the view is
when all you have is a hammer, everything looks like a nail.
I'd love for someone to show me... no... convince me, of a
typesafe language that can be used in such a place.
Not sure I get your drift here. Did you mean in commercial systems
or in OS kernels or something else? (Cut me some slack; I've only
had 2 cups of coffee so far. ;-)
I have yet to see it for production code, used on a regular basis.
Here at Qwest, we've been pretty much exclusively using nothing else
besides Java and C# since the last 6 years. (Java for about 6+ years
and C# for the past 2 years.)
So buffer overflows are pretty much things of the past, but developers
still don't validate most of their input data so there's still plenty
of XSS and SQL injection problems left. (IMO, these are just another
example of failure to do proper data validation, as are buffer overflows.)
[...snip...]
... Nor is right to assume you can use
typesafe languages as the panacea for secure coding.
To be sure, about 50% of the security holes that I still see are
the results of dumb design decisions (e.g., no authorization checks
whatsoever, placing sensitive data in persistent cookies, etc.).
Keeps my team plenty busy. ;-)
OTOH, I'm sure we'd be a lot worse off if developers here were still
allowed to use C or C++ to write new code in.
Cheers,
-kevin
---
Kevin W. Wall Qwest Information Technology, Inc.
[EMAIL PROTECTED] Phone: 614.215.4788
The reason you have people breaking into your software all
over the place is because your software sucks...
-- Former Whitehouse cybersecurity advisor, Richard Clarke,
at eWeek Security Summit
Re: [SC-L] Interesting article on the adoption of Software Security
Andreas Saurwein wrote: Crispin Cowan wrote: However, where ever C made an arbitrary decision (either way is just as good) PL/M went the opposite direction from C, making it very annoying for a C programmer to use. Does that mean it did not make any decision at all? What was the outcome? No, just trivial decisions on syntax. It made my fingers hurt to use it, because I had to retrain a lot of habits. Unfortunately I no longer remember the specifics. When you've been around for a while, you start to see the same features converge.. UNIX had quotas, we got Quotas with Win XP Server (well earlier, when you include the third party ISVs - as an add on). IBM had Language Environment (LE) before .NET come along. Crispin Cowan wrote: I think .Net borrows most heavily from Java. Java in turn borrows from everyone. The managed code thing in particular leads back to the Pascal P-code interpreter; a kludge to make the Pascal compiler easier to implement and port. The innovation in Java was to take this ugly kludge and market it as a feature :) Michael S Hines wrote: I'm not sure that it can be blamed on Pascal. Microsoft was shipping Excel for the Mac in the early 80's as P-Code application and has been selling P-Code generating compilers since about the same time. Ever since, MS was strong on P-Code generating compilers. The UCSD Pascal P-Code system was released in 1978 http://www.informationheadquarters.com/History_of_computing/UCSD_p-System.shtml. MS Excel was released in 1984 http://www.dssresources.com/history/sshistory.html. And if anything, the above claim that MS has been using P-code since the early days of Excel only supports the claim that Pascal P-Code is the origin of the idea at Microsoft. Crispin -- Crispin Cowan, Ph.D. http://immunix.com/~crispin/ CTO, Immunix http://immunix.com
RE: [SC-L] Interesting article on the adoption of Software Security
Likewise for the IBM Mainframe operating systems MVS,OS/390,z/OS - much of which is written in (I believe) PL/M - a dialect much like PL/1. Many of our Operating Systems seem to have evolved out of the old DEC RSTS system. For example, CP/M had a PIP command. Later renamed to COPY in DOS. UNIX had a hierarchical file structure. DOS inherited this feature early on. When you've been around for a while, you start to see the same features converge.. UNIX had quotas, we got Quotas with Win XP Server (well earlier, when you include the third party ISVs - as an add on). IBM had Language Environment (LE) before .NET come along. It all sort of runs together over time - it seems. Mike Hines --- Michael S Hines [EMAIL PROTECTED]
Re: [SC-L] Interesting article on the adoption of Software Security
For those of us who write kernel mode / ring0 code, what language are you suggesting we write in? Name a good typesafe language that you have PRACTICALLY seen to write kernel mode code in. Lisp. I used Lisp Machines back when I worked in academia, and almost everything was in Lisp, including most of what would in a more conventional OS be called the kernel. Of course, the Lisp dialect they used was not, strictly, typesafe, since it had subprimitives that allowed you to assemble arbitrary lispvals out of nothing. (In fact, I submit that a language that does not have some analog thereof _cannot_ be suitable for writing the lowest-level kernel code, though it may be fine for the more disciplined parts of the kernel. Vide infra.) Especially on Windows and the Linux platform. If you're restricting yourself to OS Foo, then you will have a very hard time finding a language suitable for OS hacking except for the language(s) that Foo is written in. For example, you are unlikely to have an easy time of doing Linux kernel code in any language but gcc. What is the C language downfall is also its best strength. Yes. It's a little like a Formula 1 racecar: touchy, unforgiving...and a good deal more powerful than your average car. Of course, you don't go shopping for groceries in a F1 racecar; C is not always the right answer. But simply because it does not force code to be typesafe does not automatically make it the wrong answer, either. (For example, I have trouble imagining how you could build the VM subsystem in a language that did enforce type safety.) The problem is not C. The problem is using C when it's not the right language. Note also that the right language varies not only with the problem, but with other things too, such as who's going to be writing the code. (As a simple example, C is a right language for more problems for me, who's been using it for going on twenty years now, than it is for someone who got a little of it in half of a course last semsester but really knows Visual BASIC inside and out.) /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML [EMAIL PROTECTED] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
RE: [SC-L] Interesting article on the adoption of Software Security
At 9:16 AM -0500 6/11/04, Michael S Hines wrote: IBM had Language Environment (LE) before .NET come along. What is Language Environment (for either of those) ?
Re: [SC-L] Interesting article on the adoption of Software Security
Michael S Hines wrote: Likewise for the IBM Mainframe operating systems MVS,OS/390,z/OS - much of which is written in (I believe) PL/M - a dialect much like PL/1. If PL/M is the language I am remembering from an embedded systems class back in the 1980s, then it is not at all like PL/1. Rather, it is a completely type-unsafe language. I would say similar to C, in that it has most of the same pitfalls. However, where ever C made an arbitrary decision (either way is just as good) PL/M went the opposite direction from C, making it very annoying for a C programmer to use. Many of our Operating Systems seem to have evolved out of the old DEC RSTS system. For example, CP/M had a PIP command. Later renamed to COPY in DOS. True. When you've been around for a while, you start to see the same features converge.. UNIX had quotas, we got Quotas with Win XP Server (well earlier, when you include the third party ISVs - as an add on). IBM had Language Environment (LE) before .NET come along. I think .Net borrows most heavily from Java. Java in turn borrows from everyone. The managed code thing in particular leads back to the Pascal P-code interpreter; a kludge to make the Pascal compiler easier to implement and port. The innovation in Java was to take this ugly kludge and market it as a feature :) Crispin -- Crispin Cowan, Ph.D. http://immunix.com/~crispin/ CTO, Immunix http://immunix.com
Re: [SC-L] Interesting article on the adoption of Software Security
Damir Rajnovic wrote: While this is true that only some of the bugs are fixed that fixing can have unexpectedly high price tag attached. No matter how do you look at this it _is_ cheaper to fix bugs as soon as possible in the process (or not introduce them at the first place). This is true in the isolation of looking at the cost of fixing any one individual bug, but it is not true in general. Fixing one bug early in the process is cheap and easy. Fixing the *last* bug in a system is astronomically expensive, because the cost of *finding* bugs rises exponentially as you further and further refine it. Worse, you eventually reach a point of equilibrium where your chances of inserting a new bug in the course of fixing a known bug are about even, and it becomes almost impossible to reduce the bug count further. Personally, I do not see how this can be easily measured. This entire area is rife with mushy psychological issues involving huan's ability to process information correctly. As a result, nearly all of the absolute statements are wrong, and they function only within certain ranges, .e.g. fixing bugs early in development is cheaper than patching in the field, but only within the bounds of digging only so hard for bugs. But even this statement is self-limiting. The above claim is not true (or at least less true) for safety-critical systems like fly-by-wire systems and nuclear reactor controllers, where the cost of failure due to a bug is so high that it is worth paying the extra $$$ to find the residual bugs in the development phase. My reaction to the feuding over whether it is better to shore up C/C++ or to use newer safer languages like Java and C#: each has their place. * There are millions of lines of existing C/C++ code running the world. Holding your breath until they are all replaced with type safe code is not going to be effective, and therefore there is strong motive to deploy tools (e.g. StackGuard, RATS, etc.) to improve the safety of this code. * New code should be written in type safe languages unless there is a very strong reason to do otherwise. Crispin -- Crispin Cowan, Ph.D. http://immunix.com/~crispin/ CTO, Immunix http://immunix.com
Re: [SC-L] Interesting article on the adoption of Software Security
* Kenneth R. van Wyk: There's an interesting article out on Net-Security.org (see the full article at http://www.net-security.org/article.php?id=697) that addresses why software development organizations adopt (or do not adopt) a Software Security development methodology. Check it out -- it's a good read, IMHO. | Although consuming between 5-15% of a project's overall budget, | organisations have learnt that the savings yielded by phased | security assessments far outweigh the costs of performing them. I don't think this is correct. The costs for fixing bugs is higher later in the product lifecycle (and the article cites confirming data), but these costs might never materialize. Only a fraction of all bugs are found, and the vendor doesn't even have to fix all those which have actually been discovered. I've never seen any hard evidence that investment into proactive measures during development (or call it increased software quality) pays off in the end, at least in the area of applications which are neither safety-critical nor regulated in some form or other. Only those companies that want you to pay dearly for their services publish claim after claim that those services actually save you money. My own experience suggests that a strong brand is far more significant in making purchasing decisions than defect rate, and a really good brand can enable a vendor to push critical security fixes back years, towards the next software development/deployment cycle, thus minimizing the costs. -- Current mail filters: many dial-up/DSL/cable modem hosts, and the following domains: bigpond.com, di-ve.com, fuorissimo.com, hotmail.com, jumpy.it, libero.it, netscape.net, postino.it, simplesnet.pt, spymac.com, tiscali.co.uk, tiscali.cz, tiscali.it, voila.fr, yahoo.com.
