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] OWASP Publicity
> The vast majority of IT executives are unfamiliar with all of the > principles of security, firewalls, coding, whatever. > The important thing to understand is that such principles are below > their granularity; the[y] are *right* to not care about such > principles, because they can't do anything about them. Perhaps - but then, they have to stop second-guessing the people who *do* know what they're talking about. Trying to have it both ways - management that is inexpert but nevertheless imposes their opinions on design or buying decisions - is a recipe for disaster, and, while hardly universal, is all too common. I've never understood why it is that managers who would never dream of second-guessing an electrician about electrical wiring, a construction engineer about wall bracing, a mechanic about car repairs, will not hesitate to believe - or at least act as though they believe - they know better than their in-house experts when it comes to what computer, especially software, decisions are appropriate, and use their management position to dictate choices based on their inexpert, incompletely informed, and often totally incompetent opinions. (Not just security decisions, either, though that's one of the cases with the most unfortunate consequences.) /~\ 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] 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] 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
>> 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] 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] [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] Dr. Dobb's | The Truth About Software Security | January 20, 2007
> 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] Dark Reading - Discovery and management - Security Startups Make Debut - Security News Analysis
>> Opinions on binary vs. source code (and design!) analysis, anyone? > Analyzing source code is independent of machine architecture. Only if the code is (supposed to be) architecture-independent. If the code is deliberately architecture-dependent, static analysis needs to know that, and know which the salient properties of its target architecture(s) is(are), in order to do a proper job. > Efforts which merely change attacker behavior are a waste of time. I disagree. It depends on the effort required to provoke the change, the change in attacker behaviour, and the tradeoffs involved in the threat model. To pick a historic example, fixing the "rlogin -l -froot" bug "merely" changed attacker behaviour to password guessing, but in most environments it was nevertheless a win. /~\ 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] temporary directories
>> But for a temporary file, I will specify a file that is not in any >> directory. I presume there is such a capbility in Unix. > You presume incorrectly. Yes and no. Unix does have files that do not have names in any directory. What it does not have is creation of such files without the existence (even transiently) of any name for them. To the extent that "Unix" is a single thing, that is. It wouldn't surprise me if some Unix variants had a way to do this. (If you're willing to accept a name in a directory which does not have a name anywhere except for its own ".", many of them do.) > You're talking about VMS, where you can open a file by file id. The > Unix analogue of a file id is an inode number, but no user-land call > exists to access a file that way. On many Unix variants, such a call does exist. See NetBSD's (and probably others') fhopen, for example. It's restricted to root, but it exists. /~\ 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] Cost of provably-correct code (was: bumper sticker slogan for secure software)
>> Yes, you can have provably correct code. Perhaps. But then you have bugs in the prover (and thus proof) instead. Human mistakes if it's human proof, bugs in the code for automated proof. You also have bugs in the spec that you're proving the code conforms to (unless you're simply trying to prove something like "this code never writes outside an array's dimentioned bounds", which is not what I usually take "provably correct code" to mean). /~\ 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
>> You might want to read Thompson's classic "reflections on trusting >> trust". www.acm.org/classics/sep95 > While that is always a good read, I'm not so sure it's that relevant > anymore. There is a LOT of binary analysis going on these days. Yes - but you're trusting your binary analysis tools to be intact. You're trusting the OS to give you honest copies of what's on disk. You're trusting lots of things which could be subverted - you could be talking to a complete funkspiel, in theory. At some point you have to say "the chance of the system being subverted here is low enough I'm going to ignore it". For example, when I buy transistors from the electronics shop, I don't worry about the possibility that they have enough smarts inside them to act in weird ways when used in certain applications. As a theoretical example of the kind of thing I mean, consider a transistor that, when used as a switch in a serial-line level-shifter, replaces the incoming data with other data. I choose to trust that the stuff inside the package is sufficiently close to what I think it is to not introduce any insecurities relevant to my threat model. But if my threat model included an adversary sufficiently resourceful and subtle to subvert the electronic-part distribution chain upstream of me, and the price of getting subverted were high enough, I might want to set up a small smelter/forge/whatever to make my own transistors. /~\ 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, /~\ 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] 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?
> Which brings us to the point of asking why we must have this run time > environment to protect the computing resources. Why isn't this a > function of and included in the Operating System code? Because "we" chose an OS that doesn't do that. > Is this like a firewall and IDS - just another layer we have to add > due to ineffective and insecure OS's? In a sense. But I'd put it in a way that slants it rather differently; I'd say that they are layers "we" have to add because "we" chose an OS that didn't include that stuff. It's not the OS's fault that it doesn't do something it's not designed to do. The real problem from this perspective is all the people who are picking Windows or Linux or something to run on their machines and then expecting it to have security properties it was never intended to have. Of course, if you try a "real" (from this security standpoint) OS, you will find that, as it must to achieve that level of assurance, it makes a lot of the things you've used to doing a lot harder. I suspect that between the additional up-front cost of such an OS and the inconvenience it imposes, most people prefer "add-on" security - less thorough but sufficiently less costly to tip the balance. (Actually, I suspect most people don't actually think about it and just grumble that the OS doesn't Just Do The Right Thing, even though that would require the mythical mind-reading peripheral.) > Are we dealing with symptoms or the real solution? Symptoms. The real problem is...well, depending on how you want to spin it, it could be "choosing the wrong OS for the job" or "the high cost of inconvenience" or various other things. /~\ 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] 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] Bugs and flaws
> I'm sorry, but it is just not possible to find design flaws by > staring at code. I strongly disagree with this, largely because I've done it myself. It's the primary way I find design flaws in code, in fact. Even if you add "unmotivated by a misbehaviour example", I've still done it, though on only a few occasions. /~\ 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] eWeek says "Apple's Switch to Intel Could Allow OS X Exploits"
> The article claims that Apple's use of Intel chips will result in > more software exploits because, "'Attackers have been focused on the > [Intel] x86 for over a decade. Macintosh will have a lot more > exposure than when it was on PowerPC,' Sounds likely. > I was hoping to find some hint of a hardware architectural feature > that the powerpc has that provided an additional means of protection, > but the article mentions none. Instead, the only reason that it > cites for the (presumed) increase in software exploits is attackers' > knowledge and experience base. I think that's probably fair. PPC is probably a little harder to work with because it's RISC, making it harder to write code without NULs (and a lot of injection mechanisms won't work if you have embedded NULs). However, it's not really very much harder, and attackers would have done it if the PPC target had been as big as the x86 target. > After all, didn't attackers also have access to powerpc systems to > build attacks on during the same timeframe that Symantec suggests? Sure, but less motivation to do so, because most of the machines out there were, and are, x86. /~\ 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] Spot the bug
> If you fancy yourself as a good code reviewer you can play spot the > bug at MSDN. They will be getting harder ! > http://msdn.microsoft.com/security/ Heh. They want us to do their code review for them? For free?!? I Don't Think So. :-] (Yes, I do realize that these are supposedly cases where a bug has already been found. I don't for a moment think that there will always be exactly one bug in each post, nor that they wouldn't listen to other code-review-style critiques.) /~\ 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] "Tech News on ZDNet" -- OS makers: Security is job No. 1
> We need to remember that users are generally illiterate when it comes > to the details of how their computer functions. That's why they are > USERS. They don't know (or care) how or why their computer works. > All they care about is that it does what they need for it to do. > Quite frankly, that is all they really SHOULD have to care about. Yes. But... > It is not necessary for me to understand all the gory intimate > details of how my car works in order for me to use it in a safe > fashion. The same should be true of my computer. ...the technology isn't there yet. Back in the early days of automobiles, every car owner - or at least driver - more or less had to be a decent mechanic. It took many decades to get from there to here with cars. I don't see it as at all surprising that computers - much more complex in relevant ways - aren't really ready for use by people who just want a tool, nor do I expect that to change soon. The actual problem is that people (mostly with a vested interest in increasing the computer-user population) have marketed them as usable by the blinking-twelve crowd, and we (whoever "we" are) are now faced with a mess thus created and are being expected to make the fantasy that was sold to them cone true. I for one am not interested in trying to do so - at least not in any way other than playing my own small part in the natural evolution of the field in that direction. "Dammit, Jim, I'm an OS hacker, not a miracle worker!" (Well, okay, I do do application work sometimes. :) /~\ 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] 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] 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
> [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.) > In summary: If you can state what you mean by "secure" in terms of > what must happen and what must not happen, then by using precise > specifications and automatic proof, you can achieve complete security > for all possible inputs - until the definition of "secure" needs to > be expanded. 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. Ultimately, this amounts to a VHLL, except that you're calling it a "specification" rather than "code" - and that rather than "compiling" the "code" with a program, you're using (falliable) humans, with a program (the "prover") checking that the "compiler" output is correct. And, as with any language, whoever writes this VHLL can write bugs. At some point you _have_ to ground your assurance on "Smart people looked at it and think it's OK". You can shuffle that point around, but it's always lurking somewhere. /~\ 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] [Fwd: DJB's students release 44 *nix software vulnerability advisories]
>> To have fewer bugs due to an external audit, that external audit >> would have to happen, not just be possible. > Not necessarily. Just the threat of public embarrassment [...] could > cause open source developers to be more disciplined in the first > place. This hypothesis has been around for quite some time as part > of the "open source is better" hype. > However, it is also unsubstantiated. I'm also not entirely certain it's as relevant as the discussion makes it sound. As someone who insists on source code (not necessarily open source by any of the various definitions floating around - but if *I* don't have source, I don't run it), my reasons aren't so much that I think it likely to be more nearly bug-free as much as that if I suspect a bug, I can go check, and if I encounter a bug, I can go fix it. Or at least much more nearly so. I've run into bugs in gcc that I am not competent to fix, but I've been able to fix a much higher proportion of the bugs (and nonbugs that I desire to have changed, such as feature enhancements) I've run into when I've had source than when I haven't. However, until a significant fraction of the market starts making similar choices, it won't have any significant effect on the mandates handed from managers to coders - and shops where managers hand out orders to coders are still where almost all of the code comes from, whether in terms of number of programs, number of lines, number of copies run, whatever. I've seen indications that this is starting to happen, which I (being a fairly strong source-code bigot) find encouraging. But they're still just preliminary rumblings. I'm not sure whether this list's focus is more "how do we write code more securely, assuming we have the mandate to do so" or "how do we cause more of the code written to be more secure" (or perhaps something else). /~\ 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
> 1. Features that help avoid mistakes. Such features are valuable in
> all programming domains (not just security) and include things like
> strong typing, automatic memory management, few or no automatic type
> conversions. [...]
> 2. Features that help to make the program secure and robust for all
> inputs (for example, to prevent buffer overflows). My preference
> here is for an automated tool to generate properties of the form "for
> all possible inputs to this module, this array index will be in bound
> at all times" and then generate the proof automatically (or point out
> the likely error).
I can't help thinking that this is all going to just push the errors up
a level.
When moving from machine code to assembly code, certain errors were
more or less eliminated ("oops, I forgot to update that branch
displacement to account for the extra instruction in between").
When moving from assembly code to C code, certain errors were more or
less eliminated ("oops, I forgot to allocate stack space for that new
local variable").
When moving from C code to, say, Java code, certain errors are more or
less eliminated ("oops, I forgot to update the malloc argument to
account for the extra characters").
But you'll note that in each case, errors remain - errors still occur
at the level of abstraction provided by the language in question.
(Also, as the software responsible for translating the human-written
code into machine-executable code grows in complexity, its bug level
rises correspondingly.)
This is not to say that moving up levels is worthless. But it sounds
to me as though everyone in this discussion is stuck in some kind of
mindset like "if we can just eliminate $CLASS_OF_ERROR, we'll have a
safe and secure programming language". We won't; we'll just have one
where the unsafe and insecure errors are at a higher level.
/~\ 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] Programming languages used for security
> 2. Do we need programming languages at all? Why not write precise > high-level specifications and have the system generate the program, > thereby saving time and eliminating coding error? Then the "high-level specification" _is_ the programming language, albeit a relatively unusual one, with the thing you call "the system" being what is normally called the language's compiler. Such very-high-level languages are a perennial idea. As you point out, they aren't always appropriate, but when they are they can be helpful. But they don't eliminate programming, any more than COBOL (which was supposed to make it possible to write programs in plain English and thereby eliminate programming as a skill) did. And they won't eliminate coding error. They'll eliminate certain classes of coding error, just as assembly does as compared to machine language, or as C or Pascal does as compared to assembly language - but coding errors will still occur, just as they do in assembly or C. They'll just be errors at or above the level at which the code is written. Or, of course, they'll due to be bugs in the compiler. /~\ 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
Re: [SC-L] Education and security -- another perspective (was "ACM Queue - Content")
> In general, I don't think this is an issue that is unique to _secure_ > programming (coding, design, etc.). 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 - when did you last see even a course, never mind a program, in academia that was _supposed_ to teach programming (as opposed to computer science or software engineering or any of the various other things usually taught instead of it)? I have a fuzzy memory that says that such courses exist now. But only a few of them and only very recently. /~\ 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 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] opinion, ACM Queue: Buffer Overrun Madness
> What there are _not_ are reasons for new development to cling to > languages which make flawed constructs easy for the individual > programmer to misuse. Certainly there are - or people wouldn't be doing it. Whether you or I think those reasons are good reasons is another question. (Some of the most obviously plausible: it's what the programmers know; it's what the target sytem supports; it's necessary to interface to some externally-supplied libraries) /~\ 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] opinion, ACM Queue: Buffer Overrun Madness
> Sure, it doesn't overflow into the stack, but it overflows into > important data. And if you want to go further into insanity, you can > manufacture a case where character 11 being lower case causes > unwanted code to be executed (no default condition in a 'case' > statement, no good error handling, etc). This is not as far-fetched as you make it sound. I actually ran into something not too dissimilar in the wild. Back in the late '80s, I had the dubious pleasure of tracking down the bug responsible for a mail UA breaking overnight, on a machine that was completely untouched - nothing at all had run, not even (the local equivalent of) cron jobs. It turned out to break as soon as the day number had two digits in a month whose full name was only three characters long. It broke overnight between May 9 and May 10. Y'see, what happened was, one piece of code formatted the date in the form "Fullmonthname DD" - two-digit day, with a leading space for days 1 through 9, and the month name in full. Then another piece of code converted this to the short form by skipping three characters in, dropping a terminator, looking for the next space, and picking up the day number from there. Most months, this worked fine. May 1 through 9, it worked, because the leading space on the day number stopped the scan. But May 10, the 10 was mistaken for the rest of the month name, the parser got confused, and things went downhill from 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
Re: [SC-L] opinion, ACM Queue: Buffer Overrun Madness
>> [...] the majority of computer security holes are buffer overruns. >> These would be minor irritations but for the world's addiction to >> the weakly typed programming languages C and its derivative C++. Well, actually, but for the world's addiction to sloppy coding. It's entirely possible to avoid buffer overflows in C; it just requires a little care in coding. C's major failing in this regard - and I don't actually consider it all that major - is that it doesn't provide any tools to help. It assumes that you the programmer know what you're doing, and the mismatch between that and the common reality is where the problem actually comes from. All that a "better" language will bring you in this regard is that it will (a) push the sloppiness into places the compiler can't check and (b) change the ways things break when confronted with input beyond the design underlying their code. Now, admittedly, (b) may be worth doing, other things being equal (which of course they never really are). But the basic problem is sloppy code, not the language in which it's written. (Well, most of it. People do make mistakes - but while some buffer overflows are due to someone trying to do it right and making a mistake, most of them come from not even trying. Limit it to exploitable overflows and the proportion is even higher.) /~\ 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
Re: [SC-L] White paper: "Many Eyes" - No Assurance Against Many Spies
> I have no problems with someone pointing out flaws in XYZ product > when compared to ABC product, provided: > a) they're an independent, uninvolved 3rd party > and > b) the two products are identical in feature, function, and purpose. Speaking personally, I'd say or c) The comparison is honest about its bias. That is, I have nothing against "my product is better than their product, and here are some flaws theirs has but mine doesn't". I have trouble with it only when it's disguised as an unbiased comparison. /~\ 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] Anyone looked at security features of D programming language compared to Spark?
>> Safety critical sofware has a lot of overlap with the requirements >> for high security software. > Can anyone think of any _differences_ between those domain (process > and code-wise, not regulatory-wise). Process-wise, probably not. In each case, you need to start by figuring out what your threat model is and what suitable responses are to the various possibilities, and take it from there. Code-wise, there will often be relatively large differences, but those follow directly from fairly basic differences in the threat models and response strategies. /~\ 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] Opinion re an interesting article on Linux security in Linux Journal
> To secure a machine from malware introduced by a naive user it is > required that naive users not have the privilege to introduce > software that can be executed by them or by other naive users. I would disagree. There's nothing wrong with allowing naïve users to introduce software they or others can execute - provided its execution is appropriately sandboxed. Trouble is, _that_ is hard. Java in web-browsers tried it, and gave us bugs in the jvm sandbox. Also, what the sandboxes should permit the sandboxed software to do varies from site to site, and in some cases from machine to machine, and some of those sites don't have anyone competent to figure out what the restrictions should be for them, much less correctly configure the sandbox to implement 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
