Re: [SC-L] GCC and pointer overflows [LWN.net]

2008-05-01 Thread der Mouse
 The bug, which has been documented in a CERT advisory, affects C code
 in which, under some circumstances, buffer bounds checking can be
 optimized out to produce binaries that are susceptible to buffer
 overflows.  [...]

 Of course, many/most SC-Lers will no doubt jump on this as another
 example of why C is such a dangerous language to write (secure) code
 in, and that's fine.

Actually, it isn't.  It's a dangerous language to write sloppy, buggy
code in.  Go read the advisory - it's only severely broken tests that
are affected.  Such code has always been broken; the recent change just
changes the behaviour produced by such broken code, and I have trouble
getting worked up about it.

 But, I see the issue at least a little differently: a compiler making
 decisions for the programmer and producing executable code that does
 not accurately conform to what the programmer coded.

It accurately conforms to what the programmer coded, just not to what
the programmer intended to code.  The problem affects only code that
depends on certain pointer computations whose behaviour has never been
promised by C.

/~\ 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
___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___


Re: [SC-L] Insecure Software Costs US $180B per Year - Application and Perimeter Security News Analysis - Dark Reading

2007-11-30 Thread der Mouse
 Just as a traditional manufacturer would pay less tax by
 becoming greener, the software manufacturer would pay less
 tax for producing cleaner code, [...]
 And all of this completely ignores the $0 software market.  Who
 gets hit with tax when a bug is found in, say, the Linux kernel?
 [T]f we grant that [the idea is] appropriate for for-fee software,
 it's easy decide what happens with free software - though you won't
 like the answer:  The user of the software pays anyway.

Well, it's full of enforcement issues; with for-pay, the point of sale
is a comparatively well-regulated point at which taxes can be applied,
but there is no such convenient choke-point for gratuit software.  How
would you even *find* all the relevant users?

Also, in the open-source world, people mix-and-match software to a
degree not seen in the closed-source world.  Does everyone who ever
downloaded a copy pay?  Everyone who's still running it?  Everyone who
ever ran it?  What about people who fixed the relevant bug themselves?

The only answers I can see are (1) to completely forbid software
sharing between end users, even when it's not against copyright law, or
(2) a massive DRM-style invasion of everyone's machines, so as to
report exactly what software they're running to some enforcement
authority.  I can't see either one flying.

And, incidentally, why would you think I wouldn't like that answer?  As
far as I know I'm not under any jurisdiction considering such a stupid
idea (yes, I consider it stupid), and if some other jurisdiction wants
to break their software industry that badly, it's their lookout.

 The argument the author is making is that security problems impose
 costs on *everyone*, not just on the party running the software.
 [...externalities...]
 Imposing a tax is the classic economic answer to such a market
 failure.  The tax's purpose is (theoretically) to transfer the
 externalized costs back to those who are in a position to respond.
 In theory, the cost for security problems - real or simply possible;
 we have to go with the latter because by the time we know about the
 former it's very late in the game -

So?  Why is that a problem?  It seems to me that someone who runs, say,
Windows, with all its horrible security record, in such a way as to not
cause a problem (this is not a hypothetical case), should not be taxed,
because that user is not imposing any externalized costs on the world
at large.

There's a problem finding everyone who's offended, but it's no worse
than the problems of finding all users of a piece of gratuit software.

 should be born by those who develop the buggy code, and by those who
 choose to use it.

I can argue both ways wrt imposing it on the developers.  Often enough,
the bugs are not bugs, but rather an end user misapplying software.
I've often enough written software that was perfectly fine in its
intended application but, if misapplied, could be a risk.

/~\ 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
___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___


Re: [SC-L] Insecure Software Costs US $180B per Year - Application and Perimeter Security News Analysis - Dark Reading

2007-11-29 Thread der Mouse
   Just as a traditional manufacturer would pay less tax by
   becoming greener, the software manufacturer would pay less
   tax for producing cleaner code, [...]

 One could, I suppose, give rebates based on actual field experience:
 Look at the number of security problems reported per year over a
 two-year period and give rebates to sellers who have low rates.

And all of this completely ignores the $0 software market.  (I'm
carefully not saying free, since that has too many other meanings,
some of which have been perverted in recent years to mean just about
the opposite of what they should.)  Who gets hit with tax when a bug is
found in, say, the Linux kernel?  Why?

/~\ 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
___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___


Re: [SC-L] Harvard vs. von Neumann

2007-06-11 Thread der Mouse
 Like it or not, the Web doesn't work right without Javascript now.

Depends on what you mean by the Web and work right.  Fortunately,
for at least some people's values of those, this is not true.

/~\ 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
___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___


Re: [SC-L] Harvard vs. von Neumann

2007-06-11 Thread der Mouse
 What Turing actually tells us is that it is possible to construct
 programs that may be correct but whose correctness is not decidable.
 This is a far cry from saying that it is not possible to build
 well-structured programs whose correctness _is_ decidable.

True as far as it goes - but don't forget that you also haven't shown
the latter to be possible for programs of nontrivial size.

 The higher the level in which the human codes, the [fewer] mistakes
 there are to be made, assuming equal familiarity with the language
 etc.

...but the more complex the compiler, and the greater the likelihood
of bugs in it causing the resulting binary to fail to implement what
the human wrote.

 And you are just repeating the same fallacious proposition by saying
 you cannot have total correctness.

It simply has not been formally established.  This does not make it
wrong, just unproven.  (Personally, I don't think it is wrong.)

 Had you instead said you can never be sure that you have established
 that the requirements capture the users' needs, I would have had to
 agree with you.

That too.

There are three places where problems can appear: (1) the
specifications can express something other than what the users
want/need; (2) the coders can make mistakes translating those
specifications to code; (3) the translation from code to binary can
introduce bugs.  (No, step (2) cannot be eliminated; at most you can
push around who the coders are.  Writing specifications in a formal,
compilable language is just another form of programming.)

I don't think any of these steps can ever be rendered flawless, except
possibly when they are vacuous (as, for exmaple, step 3 is when coders
write in machine code).

 People need to understand that programs are vastly more complex than
 any other class of man made artifact ever, and there fore can never
 achieve the reliability of, say, steam engines.
 Same old flawed proposition.

Same old *unproven* proposition.  Again, that doesn't make it wrong
(and, again, I don't think it *is* wrong).

 We can never solve this problem. At best we can make it better.
 We can never solve the problem of being certain that we have got the
 requirements right.

We also can never solve the problem of being certain the conversion
from high-level language (specifications, even) to executable code is
right, either.  Ultimately, everything comes down to a lot of smart
people have looked at this and think it's right - whether this is
code, a proof, prover software, whatever - and people make mistakes.

We're still finding bugs in C compilers.  Do you really think the
(vastly more complex) compilers for very-high-level specification
languages will be any better?

/~\ 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
___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___


Re: [SC-L] What's the next tech problem to be solved in software security?

2007-06-09 Thread der Mouse
 Immunity from buffer overflows has been around for 30 years.  The
 fact that some set of developers choose to ignore the languages that
 provide it does not make the next environment that provides it an
 improvement for the industry.

I'd disagree - if it means a significant increase in people actually
using such environments (languages, whatever), then it's an
improvement for the industry, even if it's no theoretical advance.

/~\ 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
___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___


Re: [SC-L] Perspectives on Code Scanning

2007-06-07 Thread der Mouse
 --- the software should work and be secure (co-requirements).

And already we have trouble, because this immediately raises not only
the question what does `work' mean? but also secure against what?.

And answering that correctly requires input from the customer.  Which
we (TINW) won't have until customers recognize a need for security and
get enough clue to know what they want to be secure against.

And we all know how likely customers are to have clue (of just about
any sort).

(Actually, there are markets where the customer usually is clued.
Oddly enough, they also tend to be markets wherein software isn't
security Swiss cheese. :-)

/~\ 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
___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___


Re: [SC-L] Perspectives on Code Scanning

2007-06-07 Thread der Mouse
 And answering that [secure against what?] correctly requires input
 from the customer.  Which we (TINW) won't have until customers
 recognize a need for security and get enough clue to know what they
 want to be secure against.
 If you are asserting that the customer must tell you how many
 security features to implement based on their requirements. I'll
 agree 100%.  Stuff like, I don't need 3 types of military grade
 encryption added, I'm just doing recipe sorting.  That kind of
 stuff.

Well, I was thinking more like, needs to withstand potentially hostile
user input on this input channel, but not on that one.  As a simple
example, a webserver usually needs to withstand potentially hostile
input from the network, but not from its config file.  (If it *can*
handle a hostile config file without crashing, great.  But if there's a
choice to be made, I'd put the brain cycles into hardening the network
interface before the config-file interface.)

/~\ 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
___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___


Re: [SC-L] [Full-disclosure] Chinese Professor Cracks Fifth Data Security Algorithm (SHA-1)

2007-03-21 Thread der Mouse
 Cracking a hash would [...].  There are an infinite number of
 messages that all hash to the same value.

Yes, but there's no guarantee that this is true of any particular hash
value, such as the one you're intersted in, only that there exists at
least one hash value that it's true of.

(At least, for hash functions in general.  A *good* hash function will
of course have this property for all hash values.  I don't know whether
SHA-1 is good in this respect, though I would expect it is.)

Okay, nitpicky-mathematician mode off :-)

/~\ 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
___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___


Re: [SC-L] Dr. Dobb's | The Truth About Software Security | January 20, 2007

2007-01-30 Thread der Mouse
 One examining only source code will miss any errors or problems that
 may be introduced by the compiler or linker.  As Symantec says -
 working with the object code is working at the level the attackers
 work.

Some attackers, at least.  I have no doubt there are plenty of
attackers looking over source code hunting for logic bugs.

I would say that anyone who thinks that either source-level analysis or
binary-level analysis is the One True Answer is either talking about a
severely restricted subset or is deluded.  (Or, perhaps, is just trying
to delude others. :-)

Anything that finds bugs helps, whether it's eyeballs and brains,
binary analysis tools, source-level analysis tools, magic 8-balls,
whatever - if it finds bugs, it's good.

/~\ 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
___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___


Re: [SC-L] Could I use Java or c#? [was: Re: re-writingcollege books]

2006-11-15 Thread der Mouse
 Simple example: There's no way in pure Java that I can lock a
 process in memory.  Wrt this list, that has a lot of security
 ramifications especially on shared processors.  Sure makes hiding
 secrets a lot harder.
 Please explain that issue.

It makes it impossible to keep things like crypto keys out of swap
space.  (Looking through swap space is a relatively well-known forensic
technique for finding things like crypto keys or passwords.)

/~\ 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
___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php


Re: [SC-L] Could I use Java or c#? [was: Re: re-writing college books]

2006-11-06 Thread der Mouse
 I read this thread and I little be afraid.  I'm just ahead of a
 complete rewriting of my program.  The previous code was written in
 pure C (with an OOP looks-like somewhere).

Perhaps I'm missing something.  Why do you have to abandon C?  You
mention C++, C#, and Java, but no other languages; is there some reason
you have to use a language that tries to be object-oriented?

Also, you have said nothing about what the tradeoffs involved are.
Since this is sc-l, I assume security is involved; what does this code
need to be secure against?

It could very well be that C is the right language for you to use.
Yes, it has problems, but so do all other languages; it's just a
question of finding the language whose problems are least problematic
for you and your application, and it sounds to me as though some of the
most important problems for you have nothing to do with the languages'
capabilities per se.

/~\ 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
___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php


Re: [SC-L] Coding with errors in mind - a solution?

2006-09-05 Thread der Mouse
 if an exception is handled several call layers above, you don't have
 to copy/translate and relay the error at each layer, [...]
 But the intervening stack frames have to be (painfully) aware of the
 fact that they might terminate abruptly.

That's what unwind-protect is for.

What, you don't have unwind-protect?  Perhaps you need to fix that
first. :-)

Actually, I have found it not all that difficult.  I have (ab?)used
gcc's nested-function nonlocal-goto support as an error-handling
throw facility relatively often, and I've run into very few cases where
intervening stack frames have to be aware of the throw-through-them
potential, and none where I would say it was painful.  Perhaps that's
just an artifact of how I design my code

/~\ 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
___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php


Re: [SC-L] How can we stop the spreading insecure codingexamplesattraining classes, etc.?

2006-08-31 Thread der Mouse
 ever heard of exceptions?  They're basically goto plus limited
 state.  Spaghetti lives!

Not at all.  Exceptions are not like gotos; in particular, an exception
cannot be used to jump *into* a construct.  The major problems with
gotos are that they can be used to do branches that are downward or
sideways in the code parse tree (versus structured constructs, which
do such branches upward only).  Exceptions are upward-only branches,
and as a result don't have most of the problems gotos do.

/~\ 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
___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php


Re: [SC-L] bumper sticker slogan for secure software

2006-07-21 Thread der Mouse
 What is important is that some magic formal tool could say that some
 code in language A, where bug of type k is possible, is not
 equivalent to the version in language B, where type k bugs are
 impossible, ergo you have found a type k bug (in the absence of any
 other bug in that section of code...).

Well, no.  You know that a bug exists.  It could be in one version (you
don't know which one), or it could be in the verifier.

If you assume that the verifier is bug-free, and you assume that the
language-A version is semantically correct, then you know that a bug
exists in the language-B version.  It might be of type k or it might be
of some other type (possibly a type that can exist in language A,
possibly not).  And in any case, you have not found it; you have only
demonstrated its existence.

/~\ 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
___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php


Re: [SC-L] bumper sticker slogan for secure software

2006-07-19 Thread der Mouse
 Absolute security is a myth.  As is designing absolutely secure
 software.

 I have high hopes in formal methods.

All formal methods do is push bugs around.  Basically, you end up
writing in a higher-level language (the spec you are formally verifying
the program meets).  You are then subject to the bugs present in *that*
program (the spec) and the bugs present in the compiler (the formal
verifier).

Formal methods are a useful tool, and have a place.  But they are not a
magic bullet.

/~\ 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
___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php


Re: [SC-L] HNS - Biggest X Window security hole since 2000

2006-05-08 Thread der Mouse
 The author claims, This flaw, caused by something as seemingly
 harmless as a missing closing parenthesis, allowed local users to
 execute code with root
 Certainly that part is OS-specific.  On my VMS machine, X-windows
 processes do not run as root.

OS- and installation-specific.  Neither the above nor the article says
just which piece of X is responsible, but I don't think any X code runs
as root on my (NetBSD) machines unless I specifically do so, such as
starting a terminal emulator from a root shell.

 So, it sounds like a single byte change in the entire X src tree
 could fix a bug that could give an attacker complete control of a
 system.  Lovely...

And, of course, nobody ever bothers to say just what the problem was.
Grrr.  (Fortunately, I don't care, since I am running pre-X11R6.9.0
code, or I'd be trying to chase down the diff.)

/~\ 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
___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php


Re: [SC-L] Another example of the futility of hardwareless 2 factor authentication

2006-04-26 Thread der Mouse
 Consider the following attempt at el-cheapo (no hardware)
 authentication:  [...]

 It is possible to imagine an authentication scheme that wants to use
 something like a certificate with signing, encrypting random nonces
 etc., to verify that someone agrees to some transaction(s).  If the
 certificate is on a PC, though, it gets exposed to theft.

There is no way to avoid this (as long as you stick to the no-hardware
restriction).  You can get clever with third parties and whatnot all
you like, but anything the user's desktop can do with the data it has
(possibly including data that is typed in by the user during operation
as intended), an impostor who has the same data (lifted from disk,
snooped on keystrokes, whatever) can do equally well.

To defeat this, in principle, you need *something* the user's computer
does not have access to.  This can be as simple as the next entry on a
list of nonces (sent to the user by some other means such as snailmail)
all the way up to something as complex as the stuff underlying SecurID.

Of course, that's not to say that simpler measures can't defeat any
specific examples, such as current attacks.  You can make it moderately
difficult, in fact.  But you can't make it impossible.

/~\ 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
___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php


Re: [SC-L] 4 Questions: Latest IE vulnerability, Firefox vs IE security, User vs Admin risk profile, and browsers coded in 100% Managed Verifiable code

2006-04-07 Thread der Mouse
 If an application is a File Compression utility, then there is no
 reason why it should have access to the TCP stack.

 The problem then, is how to prevent an unprivileged user from setting
 up a File Compression utility to access TCP and establish a port to
 which an incoming connection can be made without authentication.

The problem is worse than that.  The problem becomes one of identifying
whether a particular program is something that should or shouldn't have
access to the TCP stack - or, more likely, which of several grades of
access it should have.

For example, on a typical Unix variant, there are no file compression
utilities; there are compression utilities which can be used to
compress files, but which can also be used to, say, take data from a
network connection, compress it, and send it back out that connection
in the other direction.  As such, they need to have access to send and
receive data over established TCP streams.

But then there are programs such as netcat, which to do their job need
to be able to set up listening endpoints and initiate connections.

The problem becomes one of telling the difference.  You need to either
forbid users from running un-vetted executables they provide (whether
locally compiled or not is irrelevant) or you need to trust them to
accurately state what level of access they need to the network.  The
latter is highly error-prone - just look at how many users routinely
run with admin privilege under Windows - and the former will garner
your OS widespread rejection (even if it does gain a sliver of
acceptance from those who (a) understand the security principles
involved and (b) want to run a shop that tight).

/~\ 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
___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php


Re: [SC-L] Segments, eh Smithers?

2006-04-04 Thread der Mouse
 So, if we hope to have a truly high security operating system in our
 lifetimes, then one of several things will have to happen:

 * [...]
 * [...]
 * Someone develops a security kernel that effectively fakes
   segmentation in software using conventional pages, *and* they
   get it evaluated up to EAL7.

Strictly speaking, you don't need to have it evaluated for it to be
high security.  Evaluation does not give the security; it gives
confidence in the security (or lack thereof, if it flunks).

Okay, okay, /nitpick

/~\ 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
___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php


Re: [SC-L] Re: [Full-disclosure] 4 Questions: Latest IE vulnerability, Firefox vs IE security, User vs Admin risk profile, and browsers coded in 100% Managed Verifiable code

2006-03-29 Thread der Mouse
 no, a browser written in java would not have buffer overflow/stack
 issues.  the jvm is specifically designed to prevent it ...

And of course, we all know all JVM implementations are perfect.

/~\ 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
___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php


Re: [SC-L] Managed Code and Runtime Environments - Another layer of added security?

2006-03-29 Thread der Mouse
 Der Mouse is barking up the right rathole.

:-)  That's a lovely mangled metaphor.  And, thanks for the kind words;
I'm glad to see I'm not totally out to lunch.  (I haven't been at this
for as long as you have - you write from 1965 to 1969, during which
time I was at most five years old - and it's good to get confirmation
of some of what I think I've learnt.)

 No software was written until there was an approved specification,
 with well defined interfaces and exception conditions

And here you come close, I believe, to one of the reasons this kind of
security architecture is not more done.

This kind of coding - heck, even just writing good specifications - is
hard work, work that comparatively few people are competent to do.  In
all my years at this, I can count the number of times I've seen a
really well-defined specification on the fingers of one hand.  (The
case I usually cite is the VAX Architecture Reference Manual, which is
carful to call out all the cases where the behaviour is UNDEFINED or
UNPREDICTABLE, those being technical terms defined early in the
document, and to cover every possibility with defined behaviour or one
of those.)  Almost everything has holes, cases where the spec is
silent; this is not the way to produce solid designs.  In many cases a
shaky design is no big problem (so your solitaire game crashes now and
then, so what?).  But in other cases it can be quite disastrous, with
the kind of consequences everyone here surely knows far too much about.

/~\ 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
___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php


Re: [SC-L] Managed Code and Runtime Environments - Another layer of added security?

2006-03-29 Thread der Mouse
 Multics code was not immune to buffer overflows, but in most cases
 the effect was blunted because the out-of-range index values could
 only affect data beyond the current activation record--in contrast
 with most linear addressing systems where an overflow is almost
 always able to reach important values like the return address.

This is only because the libraries used store later characters in a
string at higher addresses (as compared to earlier characters).  If the
string libraries stored strings the other way around (with the earlier
characters at the higher addresses), downward-growing stacks would have
exactly this kind of buffer overrun protection.

Hmm, I wonder if there's something useful lurking there.

/~\ 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
___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php


Re: [SC-L] 4 Questions: Latest IE vulnerability, Firefox vs IE security, User vs Admin risk profile, and browsers coded in 100% Managed Verifiable code

2006-03-27 Thread der Mouse
 At least one aspect of that is a design defect in TCP/IP, allowing
 unprivileged users to create a port to receive inbound connections.

I don't think it's fair to call that any kind of defect in TCP/IP.
There is nothing at all in TCP or IP that says anything whatsoever
about what privilege may or may not be necessary to establish a listen
for incoming connections.  If you must call this a flaw, at least place
the flaw where it actually is - in the implementation(s).

I'm also not convinced it's a flaw at all; calling it one sounds to me
like viewing a TCP stack designed for one environment from the point of
view of a drastically different environment.  In the environment most
current TCP stacks were designed for, listening for connections on a
high port should not be a restricted operation.  In calling that a
defect, you appear to be looking on it from a point of view which
disagrees with that, which actually means just that you've picked the
wrong TCP stack for your environment, not that there's anything wrong
with the stack for its design environment.

/~\ 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
___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php


Re: [SC-L] Spot the bug

2005-07-21 Thread der Mouse
 http://msdn.microsoft.com/security/
 Heh.  They want us to do their code review for them?
 Did you look at it?

I looked at the referred-to blog.  I didn't see any code, though I
didn't do much webcrawling looking for any - perhaps I was too early,
or perhaps I just missed the crucial link, or something.  (But whatever
it was, it must still be; I just now looked -
http://blogs.msdn.com/brianjo/archive/2005/07/18/440179.aspx, as linked
to by http://msdn.microsoft.com/security/ - and still can't see any
code there.  Maybe it's that [INLINE] - I didn't bother fetching images
- or maybe I need to have JavaScript or ActiveX or some such
security-disaster-waiting-to-happen to get it; I don't know.  I do see
three javascript: links, arguing in favour of the JavaScript theory.)

 The current one is a 4-line toy bug.  It's a contrived example, and
 theposter obviously already knows there is a bug.

 You think they are going to work their way up to:
 Umm... great so far, readers.  Now look at these 10,000 lines and
 tell us where the bug is...?

Basically, yeah.  When dealing with anything Microsoft, I not only look
the horses in the mouths, I am inclined to X-ray and ultrasound them,
and even then may not buy.  I don't trust Microsoft even as far as I
can throw them.

Maybe this is exactly what it appears to be.  In that case, well, good
for them, and maybe it will begin to do some epsilon of good, start
chipping away at the mountain of negative karma they've built up.

But maybe it's not, too.  And if I want examples of bad code I hardly
have to go to Microsoft to find them.

/~\ 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] Theoretical question about vulnerabilities

2005-04-13 Thread der Mouse
 [B]uffer overflows can always be avoided, because if there is ANY
 input whatsoever that can produce a buffer overflow, the proofs
 will fail and the problem will be identified.
 Then either (a) there exist programs which never access
 out-of-bounds but which the checker incorrectly flags as doing so,
 or (b) there exist programs for which the checker never terminates
 (quite possibly both).  (This is simply the Halting Theorem
 rephrased.)
 Could you explain why you believe that proof of a specific property
 in a constrained environment is equivalent to the Halting Problem?

Take the code for the checker.  Wrap it in a small amount of code that
makes a deliberate out-of-bounds access if the checker outputs `no
problem'.  Then write another small bit of code which ignores its input
and runs the wrapped checker on itself.

Run the original checker on the result.

This is basically the same diagonalization argument Turing used to
demonstrate that the Halting Problem was unsolvable; that's the sense
in which I call it the Halting Theorem rephrased.

 I really do find this line of argument rather irritating; the
 theoretical limits of proof are quite a different thing from the
 practical application of proof-based technology in a suitably
 constrained environment.

Entirely true.  But if you use theoretical language like proof, you
have to expect to be held to a theroetical standard of correctness.

/~\ The ASCIIder 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] Re: Application Insecurity --- Who is at Fault?

2005-04-12 Thread der Mouse
 The programmer is neither the application architect nor the system
 engineer.
 In some cases he is.  Either way, it doesn't matter.  I'm not asking
 the programmer to re-design the application, I'm asking them to just
 program the design 'correctly' rather than 'with bugs'

Except that sometimes the bugs are in the design rather than the code.
Module A has a spec saying that checking a certain aspect of the input
arguments is the caller's responsibility; module B, calling module A,
is written to a spec that makes it A's responsibility to check those
values.

Neither programmer is at fault; each module was written correctly to
spec.  The real problem is that the specs are incompatible - whatever
part of the design and specification process allowed the two specs for
module A to get out of sync with one another is at fault.  (This
shouldn't happen, no, but anyone who thinks that it doesn't is
dreaming.)  Sometimes even the specs are identical, but are written
badly, leaving enough unsaid for such mismatches to occur - the art and
science of writing complete interface specs, that's another subject I
could rant at some length about

 I would question you if you suggested to me that you always assume to
 _NOT_ include 'security' and only _DO_ include security if someone
 asks.

Security is not a single thing that is included or omitted.

Another common source of security problems is that a module (call it A)
is implemented in a way that is secure against the threat model then in
effect (often this threat model is unspecified, and maybe even A's
coder was careful and went and asked and was told no, we don't care
about that).  This module is then picked up and re-used (hey, re-use
is good, right?) in an environment where the threat model is
drastically different - instant problem.  Security was included, yet
security failed, and the fault does not lie with the original coder.
(It lies with whoever reused the module in an environment it was not
designed for.)

 It's also much more likely that the foreman (aka programming
 manager) told the builder (programmer) to take shortcuts to meet
 time and budget -
 Maybe, but the programmer should not allow 'security' to be one of
 these short-cuts.

The programmer quite likely doesn't have that choice.  Refusing to do
what your manager tells you is often grounds for summary firing, with
the work being reassigned to someone who will follow orders (and
probably will be even more overloaded).

It's also not always clear whether a given thing constitutes a security
risk or not.  A certain validation check that's omitted could lead to
nothing worse than, say, a one-cycle delay in recognizing a given
signal in the initial design, but reused in another way that nobody
knew even existed at first writing, it could cause a crash (and
associated DoS) or worse.

/~\ The ASCIIder 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] Re: Application Insecurity --- Who is at Fault?

2005-04-12 Thread der Mouse
 I would question you if you suggested to me that you always assume
 to _NOT_ include 'security' and only _DO_ include security if
 someone asks.
 Security is not a single thing that is included or omitted.
 Again, in my experience that is not true.  Programs that are labelled
 'Secure' vs something that isn't.

*Labelling as* secure _is_ (or at least can be) something that is
boolean, included or not.  The actual security behind it, if any, is
what I was talking about.

 In this case, there is a single thing - Security - that has been
 included in one and not the other [in theory].

Rather, I would say, there is a cluster of things that have been boxed
up and labeled security, and included or not.  What that box includes
may not be the same between the two cases, even, never mind whether
there are any security aspects that aren't in the box, or non-security
aspects that are.

 Also, anyone requesting software from a development company may say:
 Oh, is it 'Secure'?  Again, the implication is that it is a single
 thing included or omitted.

Yes, that is the implication.  It is wrong.

The correct response to is it secure? is against what threat?, not
yes or no.  I would argue that anyone who thinks otherwise should
not be coding or specifying for anything that has a significant cost
for a security failure.  (Which is not to say that they aren't!)

/~\ The ASCIIder 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] Theoretical question about vulnerabilities

2005-04-12 Thread der Mouse
 Or until you find a bug in your automated prover.  Or, worse,
 discover that a vulnerability exists despite your proof, meaning
 that you either missed a loophole in your spec or your prover has a
 bug, and you don't have the slightest idea which.
 On that basis, can I presume that you believe all programming should
 be done in machine code, in case the compiler/assembler/linker you
 might be tempted to use has a bug?

You can presume anything you like.  But in this case you'd be wrong.

I was/am not arguing that such tools should not be used (for this or
any other reason).  My point is merely that calling what they do
proof is misleading to the point where I'd call it outright wrong.
You have roughly the same level of assurance that code passed by such a
checker is correct that you do that machine/assembly code output by a
traditional compiler is correct: good enough for most purposes, but by
no stretch of the imagination is it even as close to proof as most
mathematics proofs are - and, like them, it ultimately rests on
smart people think it's OK.

 Ultimately, this amounts to a VHLL, except that
 [...nomenclature...].  And, as with any language, whoever writes
 this VHLL can write bugs.
 Like I said, you can still fail to include important security
 properties in the specification.  However, [...].

Basically, the same arguments usually made for any higher-level
langauge versus a corresponding lower-level language: machine versus
assembly, assembly versus C, C versus Lisp, etc.

And I daresay that it provides at least vaguely the same advantages and
disadvantages as for most of the higher/lower level comparisons, too.
But it is hardly the panacea that proving the program correct makes
it sound like.  As someone (who? I forget) is said to have said,
Beware, I have only proven this program correct, not tested it.

/~\ The ASCIIder 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] How do we improve s/w developer awareness?

2004-12-02 Thread der Mouse
 Changing liability laws on the other hand is a simple solution.

But at what price?  It would kill off open source completely, as far as
I can see, in the jurisdiction(s) in question.  (How many open source
projects could afford to defend a liability suit even if they (a)
wanted to and (b) had a won case?)

Of course, if you don't mind that, go right ahead.  You don't say where
you are, but looking over your message I see reason to thin it's the
USA, and I long ago wrote off the USA as a place to write code.  I
think it could be a very good thing for the USA to try such laws; it
would give us hard data about what their effect is, rather than the
speculation (however well-informed) that's all we have to go on now -
and it quite likely would have the pleasant side effect of pushing most
open source projects out into the free (or at least freer) world.

/~\ The ASCIIder 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] Programming languages -- the third rail of secure coding

2004-07-20 Thread der Mouse
 I've been compiling a list of programming languages..  [...]
 My list -- (feel free to add to it).

42. BCPL
43. sh
43. awk
44. FORTRAN
45. TeX
46. Metafont
47. PostScript
48. MUF
49. BLISS
50. Machine code

I'd also point out that if it's languages you're trying to list,
JavaScript arguably should not have a separate entry from Java (and
probably VBScript vs Visual Basic too).  I also think ADA should be
spelled Ada - you seem to be _trying_ to capitalize correctly

/~\ 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] Programming languages used for security

2004-07-14 Thread der Mouse
 The environment with which I am most familiar is VMS, and tradition
 is what guides secure interfaces.  Inner mode code _must_ probe any
 arguments provided from an outer mode, probe the buffers specified
 by descriptors provided, etc.
 What do you do when you're handed a bad pointer?

I forget whether it's returning an error code analogous to EFAULT or
raising an access violation, but I'm fairly sure it's one of them (at
least under the versions I used).  Either would be reasonable, the
latter arguably more so (just as under Unix, it would arguably be more
sensible to generate a SIGSEGV/SIGBUS rather than returning EFAULT).

/~\ 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] Programming languages used for security

2004-07-10 Thread der Mouse
 Programs written in high-level languages are *precisely*
 specifications that result in the system generating the program,

 Whilst I agree that the distinction between specification and
 programming languages is not completely clear cut, there is
 nevertheless a fundamental difference between specification and
 programming.

 In a programming language, you tell the computer what you want it to
 do, normally by way of sequential statements and loops. You do not
 tell the computer what you are trying to achieve.  [...]

This is really just arguing over what words should be used for creating
software using such languages.  You call it specification (versus
programming), others call it declarative programming (versus
imperative programming).

Personally, I think the latter is the more useful way of looking at it.
Complexity cannot, ultimately, be hidden; build a specification
language powerful enough to build a whole application and it will have
complexity enough that writing useful specifications in it demands the
kind of mental discipline that is usually thought of as programming -
and provides the same kind of capability for expressing error.  (The
errors will be at a higher level, because the language is higher level,
but they will occur if the thing being built is nontrivial.)

/~\ 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] Education and security -- another perspective (was ACM Queue - Content)

2004-07-08 Thread der Mouse
 I see both of you willing to mandate the teaching of C and yet not
 mandate the teaching of any of Ada, Pascal, PL/I etc.

 This seems like the teaching of making do.

And is not making do an important skill?

More seriously, as long as Unix variants maintain their position of
importance (something that shows no signs of going away), C will be an
important language for anyone outside academia to know - and many of
those inside academia.  As such, I would say that any program with so
much as pretensions to preparing people for the real world needs to
teach it to some extent.

Certainly not exclusively (I know I'm a better programmer for knowing
many languages).  Perhaps not even predominantly.  But as theoretically
ugly as it may be, it is still pragmatically critical.

/~\ 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] Education and security -- another perspective (was ACM Queue - Content)

2004-07-05 Thread der Mouse
 I think over the past 40 years or so, as a discipline, we've failed
 rather miserably at teaching programming, period.
 Right.  But on the other hand, that's not surprising - [because
 we've mostly not even _tried_ to teach programming, as opposed to
 computer science or software engineering].
 Care to explain what do you think a 'programming course' should have
 that is not covered in SE or CS courses (or curricula)?

A computer scientist is a theoretician.  A software engineer is a
designer.  A programmer is an implementer.

A computer scientist can prove you can't, in general, sort faster than
O(n log n) (and a good one can recast this as an explanatino of why).

A software engineer can look at the application and decide which
sorting algorithm is approproate for _this_ task, including, perhaps,
choosing one with O(n^2) worst-case behaviour because of some
application-specific property.

A programmer can sit down and implement a sorting algorithm.

There is a good deal of overlap, of course; it's rare to find anyone
who is wholly one of these without any bleedover from the others.  In
particular, any really good person in any of the three fields is going
to have a good deal of skill/knowledge from the other two mixed in.

What this means for acamdeia is less clear.  In particular, most CS and
SE programs actually include a good deal of programming, partly because
that's what many of the students actually want, partly for historical
reasons, and partly because you do need some familiarity with
programming to be a good CS or SE (just as you need some CS/SE to be a
good programmer).

Thus, to really separate the programs, you'd have to pull the
programming out of the CS and SE curricula and put them in a
programming curriculum, perhaps with some new material added.  I'd
actually argue for going the other way, though, since the lines between
the areas are actually rather artificial, drawn not so much because
there really are boundaries there as because humans like to draw
boundaries around things.

What this has to do with _secure_ coding...well, nothing, directly.
But part of teaching programming really ought to be teaching the
security side of it, and whether you call it CS or SE or programming,
that's something I agree academia has mostly failed at.

Security for CS includes things like a bit of cryptography, some of the
mutant complexity theory that considers a problem that's O(1) 99% of
the time O(n^n) the other 1% easy rather than hard; security for SE
includes things like writing interface contracts that specify what
_isn't_ defined as well as what _is_; security for programmers includes
things like not overrunning buffers.  Again, there's a lot of overlap.

/~\ 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




[no subject]

2004-06-18 Thread der Mouse
be part of
it anyway.
Date: Thu, 17 Jun 2004 11:56:48 -0400 (EDT)
To: [EMAIL PROTECTED]
Subject: Re: [SC-L] Origins of Security Problems
In-Reply-To: [EMAIL PROTECTED]
References: [EMAIL PROTECTED]
[EMAIL PROTECTED]
X-Virus-Scanned: Secured by aspStation
Sender: [EMAIL PROTECTED]
Precedence: bulk
Mailing-List: contact [EMAIL PROTECTED] ; run by MajorDomo
List-Id: Secure Coding Mailing List sc-l.securecoding.org
List-Post: mailto:[EMAIL PROTECTED]
List-Subscribe: http://www.securecoding.org/list/
List-Unsubscribe: http://www.securecoding.org/list/
List-Help: http://www.securecoding.org/list/charter.php
List-Archive: http://lists.virus.org
Delivered-To: mailing list [EMAIL PROTECTED]
Delivered-To: moderator for [EMAIL PROTECTED]

 A significant difference from DECnet is that with TCP/IP any user on
 the system can open up a channel (to use a neutral term) to receive
 incoming traffic,

This is not so much a difference between DECnet and IP as a difference
between VMS and Unix.

/~\ The ASCIIder 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

2004-06-11 Thread der Mouse
 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] Andy Tanenbaum on Linux's origins and security

2004-05-21 Thread der Mouse
 At the very end of the document, [Andy Tanenbaum] talks about the
 security of a microkernel system like (his own) MINIX vs. that of a
 monolithic kernel like Linux.  He writes, With all the security
 problems Windows has now, it is increasingly obvious to everyone that
 tiny microkernels, like that of MINIX, are a better base for
 operating systems than huge monolithic systems.

This is an amazing leap of illogic.  I see no particular reason to
ascribe _any_ of Windows' insecurity to its monolithic architecture (as
opposed to, say, Microsoft's duty to its shareholders to cut quality,
and therefore costs, as far as is not inconsistent with the result
still selling).

 [A.T. writes further:] As I did 20 years ago, I still fervently
 believe that the only way to make software secure, reliable, and fast
 is to make it small.  Fight Features.

Indeed.  And still with no bearing on whether the system putatively
containing those features is designed microkernel or monolithic.  In
view of this, comparing against Linux (a kitchen-sink system if I ever
saw one) is unfair; he should be comparing against one of the BSDs, if
he wants an open-source monolithic Unix variant.

There _are_ security benefits to microkernel designs, it's true, but
there are also security benefits to monolithic designs, and which
outweighs the other is a decision each system's architect must make -
it certainly isn't a slam-dunk either way, to me.

/~\ 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