Lambda the Ultimate

inactiveTopic Windows security flaw - buffer-overflow
started 7/20/2003; 1:39:32 AM - last post 7/25/2003; 9:25:04 AM
Dan Shappir - Windows security flaw - buffer-overflow  blueArrow
7/20/2003; 1:39:32 AM (reads: 2321, responses: 20)
Windows security flaw - buffer-overflow
Yet another Windows security bug. Suprise, suprise.

What caught my in the article was the following statement:

It's not surprising that the flaw found its way into Windows Server 2003, said Russ Cooper, an analyst at Reston, Va.-based TruSecure Corp. and moderator of the popular NTBugtraq mailing list. "For all its work, Microsoft knows that solving the buffer-overflow problem is not going to happen," Cooper said. "They can reduce the number, minimize the effects for some services, but [neither] they nor anyone else can get rid of them, no matter what hype is associated with it."

Maybe he ment that solving the buffer-overflow problem within the exisiting Windows code-base is not possible. If he ment it in a general was, do you accept it ? (taking a PL-centric view of course)
Posted to Software-Eng by Dan Shappir on 7/20/03; 2:53:17 AM

Ehud Lamm - Re: Windows security flaw - buffer-overflow  blueArrow
7/20/2003; 2:56:01 AM (reads: 1448, responses: 0)
Taken literally this is such an idiotic statement, that one has to conclude that the guy has something more specific in mind...

Frank Atanassow - Re: Windows security flaw - buffer-overflow  blueArrow
7/20/2003; 5:39:08 AM (reads: 1498, responses: 1)
We must not be critical of Microsoft because their software seems incapable of converging to a limit.

Rather we should praise them for its flexible, postmodern nature: one cannot pigeonhole software by such outmoded and meaningless labels as `correct', `secure' or `reliable'. Modern software developers know that such terms are only artificial categories invented by sophists to simplify reality and so oppress developers.

The sophist says, `Users demand correct software.'

The developer rightly replies, `Correctness is an illusion. The program exists or it does not exist; it behaves as it behaves. Motibo ergo sum.'

The sophist counters, `What users want is an illusion?'

`No. We exist only to serve. Such is our purpose. But our masters are fickle,' says the developer. `They do not know their minds, which are clouded by their own desires.'

`How can you serve your master when you do not acknowledge his desires?'

`We are clever and nimble. Though a chasm lies between us, our master may say, ``Come hither,'' and we run elsewhere very quickly, knowing his true mind.'

`Why do you not build a bridge?'

`We have no such art; do you think us engineers?'

`Then why do you not tell him you cannot please him?'

`Simpleton! Who bites the hand that feeds? He is anywise oft amused by our agile antics. We do not go where he asks, but where we go, we go quickly.'

Here endeth the lesson.

Marc Hamann - Re: Windows security flaw - buffer-overflow  blueArrow
7/20/2003; 7:24:14 AM (reads: 1409, responses: 1)
My gut feeling on reading the quote was the he must be a C/C++ programmer who realizes from experience that where there are pointers there are buffer overflows.

I'm guessing the "radical" solution of constraining pointer use or using a language that makes it easier to detect and avoid overflows has been ruled out a priori by the large code base and his lack of imagination. ;-)

Marc Hamann - Re: Windows security flaw - buffer-overflow  blueArrow
7/20/2003; 7:49:54 AM (reads: 1477, responses: 0)
Thanks for the amusing Sunday morning read, Frank. I'm starting to think that you secretly want to leave CS and become a writer. ;-)

Though you have created a convincing parody of the worst excesses of software development, it is also an accurate parody of almost ANY human activity.

It seems that to some extent you think programming should NOT be a human activity, but a tightly-constrained mathematical one.

And though I understand the impulse, and have felt it myself, there aren't ANY domains that I know of that AREN'T subject to the kinds of human factors you lampoon.

Science, engineering, even mathematics itself, are subject to social pressures such as pleasing academic supervisors, appealing to journals, reflecting the latest fads in the field, etc.

And this isn't a strange "impurity" in these activities, but a side-effect of their core function: to expand the bounds of human knowledge and power. Since humans are humans, so is everything we do infected with human foibles.

At this point we can throw our hands in the air and say "what's the point then?", but my prefered approach is to find ways to be effective in spite of the vagaries of human behaviour.

In a PL context, this means understanding what features people like and dislike, find intuitive and unintutive, what disciplines are simple enough that people will follow them, etc. and take that knowledge to build a language that is human-tolerant and relatively safe.

Frank Atanassow - Re: Windows security flaw - buffer-overflow  blueArrow
7/20/2003; 8:13:34 AM (reads: 1405, responses: 1)
I'm starting to think that you secretly want to leave CS and become a writer. ;-)

You may not be far wrong...

It seems that to some extent you think programming should NOT be a human activity, but a tightly-constrained mathematical one.

Mathematics is a human activity!

Indeed, it's a characteristically human activity, as we learned when Gödel showed us that (non-trivial) mathematics is one of the things a machine can't do.

So if you aren't sure sometimes
If you control your UNIX box
Or it's controlling you,
Show it who's the boss:
Prove a theorem or two!

Blecch... that needs some work.

And though I understand the impulse, and have felt it myself, there aren't ANY domains that I know of that AREN'T subject to the kinds of human factors you lampoon.

I wasn't lampooning human factors at all (except the `bite the hand that feeds me' part, which I put in out of spite) but rather intended to show that `agility' is meaningless without correctness.

Bart van der Werf (Bluelive) - Re: Windows security flaw - buffer-overflow  blueArrow
7/20/2003; 9:12:08 AM (reads: 1381, responses: 1)
Well maybe its time someone filled the aparant void between c/c++ and something that compiles nativly that does some thing that either replaces or makes pointer operations save.

Isaac Gouy - Re: Windows security flaw - buffer-overflow  blueArrow
7/20/2003; 9:34:23 AM (reads: 1369, responses: 0)
The Road Not Taken wraps-up these security failures on slide 26

Marc Hamann - Re: Windows security flaw - buffer-overflow  blueArrow
7/20/2003; 10:22:51 AM (reads: 1390, responses: 0)
Mathematics is a human activity!

I agree completely.

but rather intended to show that `agility' is meaningless without correctness

I don't think this is controversial in and of itself; the tricky part is what you think it means to be correct. One definition is: "proven by theorem to be equivalent to some specification". Another is: "Conforms to the expectations of the boss or user".

There not mutually exclusive, but they are not identical either.

Lou Glassy - Re: Windows security flaw - buffer-overflow  blueArrow
7/20/2003; 1:41:09 PM (reads: 1316, responses: 1)
[1] A friend of mine doing embedded systems work, wrote a fairly interesting (~20KSLOC) electronic sign controller in Ada.

The final product he shipped had no observable buffer overruns. (He was a "army of one" so to speak, tested his code in numerous ways, and had written exception handlers that no test he could come up with, ever triggered.)

So - the statement "buffer overruns are inevitable" only makes sense when you write complex systems in low-level languages, and in particular, when you write in a low-level way, in those languages.

[2] Frank, thanks for today's lesson. That was a hoot. :-)

[3] There was an article sometime in the 80s in Software Practice and Experience (Welsh? is that the author?) called "Efficient Range Checks in Pascal." The gist: in Pascal, one could provide 100% coverage in array bounds checks, for an overhead of something like 20% in run time. (The 100% coverage was a combination of actual run-time checks, and other instances in which you could prove the check would never fail, in which case you eliminated it. Think about iterating over a suitably-defined array type whose index is an enumerated type, as an example.)

I don't know enough of deep compiler theory to know how "20% hit for Pascal" translates to C or C++. My understanding is that C (etc) has various horrors in its type system that make array bounds checking hard enough to implement, that no vendor does it.

[4] Every programming language comes pre-attached to a culture --- a set of values speakers share, and that programs they write, embody. (warning, gross overgeneralizations follow) The Ada culture favors readability. The Haskell culture favors proveability. The Lisp culture favors hackability. The C culture favors, uh, constant employment.

I write "constant employment" only partly tongue-in-cheek. C programming for large, complex systems -- the more horrendous the data structures, the better -- is a test of manhood. The correctness of the end-result is secondary to the awe inspired by having the system work *at all*. And if the system is hard to modify, well, you can always pay me to continue working on it, right?

In my observation, non-C/C++ cultures seem to revolve around other core values (correctness, dynamism, expressiveness, etc). and Microsoft? Microsoft is a undying bastion of C culture.

Ehud Lamm - Re: Windows security flaw - buffer-overflow  blueArrow
7/21/2003; 1:33:17 AM (reads: 1231, responses: 0)
Achieving buffer overflows in Ada is not simple: You must really want them, to put them in..

Kevin Kelleher - Re: Windows security flaw - buffer-overflow  blueArrow
7/21/2003; 4:52:40 AM (reads: 1185, responses: 0)
The buffer-overflow problem is an internet security problem. When an application (such as a web server) is listening for input on a port, it's possible to send commands to the underlying operating system by sending lines that are too long for the input buffer.

For example, if someone wrote a webserver and was fool enough to use an buffer of 80 characters to process input, and someone sent a message longer than 80 characters, the spillover would fall into the operating system and be executed as a command inside the host system.

This problem was fixed pretty quickly in the Apache webserver.

Microsoft's problem is that their webserver is closely integrated with their operating system, and therefore can access quite a few libraries on the host, and so the MS coders would have to go through each one of Microsoft's DLLs and find all the potential buffer-overflow problems, and then fix them.

Isaac Gouy - Re: Windows security flaw - buffer-overflow  blueArrow
7/21/2003; 8:11:10 AM (reads: 1104, responses: 0)
Tony Hoare on implementing Algol 60 (in 1961)
(1) The first principle was security: ...
A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array.

Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to - they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous.

Ziv Caspi - Re: Windows security flaw - buffer-overflow  blueArrow
7/21/2003; 10:36:46 PM (reads: 997, responses: 1)

Microsoft is a undying bastion of C culture.

On the contrary. Externally, the source code for most of Microsoft's products is not shipped with the product, so Microsoft as a company gains nothing by making it difficult to work with.

Internally, writing complex code would (1) make it more difficult to pass code reviews, and (2) make it more difficult to transfer to other interesting projects (because your lead would not want to give you up).

Ehud Lamm - Re: Windows security flaw - buffer-overflow  blueArrow
7/21/2003; 11:37:59 PM (reads: 1014, responses: 0)
One thing worth noting about Microsoft is their undying fasination with programming languages, and their willingness to invent new ones (e.g., VB, C#). I always thought this is the main cause of Microsoft's success...

Patrick Logan - Re: Windows security flaw - buffer-overflow  blueArrow
7/22/2003; 6:44:08 AM (reads: 962, responses: 1)
I always thought this is the main cause of Microsoft's success...

I think you are on to something. The company really goes after the developer mind share.

But all language providers seem to have a need to always "upgrade" their languages with more features. Perl, Python, Java, C# it doesn't matter. OSCON, Java One, and whatever it is MSFT has all have sessions on what's next for these languages.

If developers had a sense of history, they might be content with a language that has garbage collection and classes or functions. Those were the hills that needed to be climbed IMO. Everything else (iterators, generics, XML, AOP, etc.) is icing on the cake.

Ehud Lamm - Re: Windows security flaw - buffer-overflow  blueArrow
7/22/2003; 7:37:24 AM (reads: 972, responses: 0)
So the CLI supports them.

Anyway, I was thinking about the "eat your own dogfood" mentality, which is related but not identical to going after the developer mind share (they are developers after all...)

scruzia - Re: Windows security flaw - buffer-overflow  blueArrow
7/22/2003; 10:20:02 AM (reads: 955, responses: 0)
Bart van der Werf wrote that it was time to for a pointer-safe dialect of C ...

Cyclone ( http://www.research.att.com/projects/cyclone/ ) is probably the best known project that does this.

Isaac Gouy - Re: Windows security flaw - buffer-overflow  blueArrow
7/24/2003; 10:36:05 AM (reads: 838, responses: 1)
As we so recently discussed this issue, note that there's yet another buffer-overflow flaw - which even made it onto the BBC main news pages.

Cyclone and Vault (a somewhat similar MS research project) have been mentioned on LtU.

Ehud Lamm - Re: Windows security flaw - buffer-overflow  blueArrow
7/25/2003; 12:24:08 AM (reads: 841, responses: 0)
And I keep mentioning Ada...

Isaac Gouy - Re: Windows security flaw - buffer-overflow  blueArrow
7/25/2003; 9:25:04 AM (reads: 802, responses: 0)
And I keep mentioning Ada...
And so you should! (there's an IDE for GNAT now)
These buffer-overflow faults seem to be so amenable to a language solution - if you're in a hole, stop digging!