Re: [SC-L] GCC and pointer overflows [LWN.net]
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
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
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
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
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?
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
--- 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
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)
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] Could I use Java or c#? [was: Re: re-writingcollege books]
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]
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?
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.?
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
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
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
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
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
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?
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
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?
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?
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
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
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
[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?
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?
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
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?
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
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
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
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)
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)
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]
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
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
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
