Re: [SC-L] ACM Queue article and security education
ljknews wrote: I think it will be properly considered when the most strict portion of the software world is using language X. I have used many programs where the flaws in the program make it clear that I care not one whit about whether the authors of that program have opinion about anything I might use. They are simply not competent, either as individuals or else as an organization. By most strict portion, do you mean people that care most about correct code, proofs, and such? I don't deny that the bulk of the heavy lifting will be done by people well-qualified to do so. However, I'm of the school of thought that certain types of people who like to break things, and whose chief skill is breaking things, will always have a decent shot at finding a problem. There are people who couldn't build it, but they can sure break it. You don't typically get their attention until something is really, really popular. So yes, you can write your stuff in Language X, and assume it's secure. It might not actually be until the whole world has had its way with Language X, but (hopefully) that's not a problem. You can still do the dance of patching the last 5 problems in Language X, and end up better off that if you'd just used C. Even Knuth has to write checks ocassionally, and he does a lot of proof work, doesn't he? So, if Language X only has 5 problems total, even if it takes years to ferret them out, butthey are fixable, please proceed with getting the whole world to use Language X. BB
Re: [SC-L] ACM Queue article and security education
Peter Amey wrote: I'm not entirely sure I follow this. I _think_ you are saying: since we can't be sure that X is perfect (because it might have 5 remaining flaws) then there is no point in adopting it. You seem to be saying that it doesn't matter if X is _demonstrably_much_better_ than Y, if it is not perfect then don't change. Have I got that right? No. I was claiming that languages that allow for safety and verifiction can't neccessarily be trusted 100%. There will always be a last few bugs. As I said in my note that you replied to, that doesn't neccessarily mean you don't use it. The other part of my note had to do with the last few bugs not coming to light until *everyone* is using that language. Also not a reason to not go ahead and use it now, since the sooner the world starts to switch, the sooner you kill the last few bugs. I think you were reacting to the one sarcastic part of my note, which essentially says good luck getting the world to switch. BB
Re: [SC-L] Education and security -- another perspective (was ACM Queue - Content)
Jose Nazario wrote: rather than talking in a vacuum, make sure you've read the latest ACM/IEEE-CS curriculum guidelines: http://www.acm.org/education/curricula.html http://sites.computer.org/ccse/ Hrm. I checked both pages, and searched for secur, and got nothing. I didn't click every link... security is mentioned briefly in a couple of places in the ACM strawman. Was that your point? BB
Re: [SC-L] Education and security -- another perspective (was ACM Queue - Content)
Fernando Schapachnik wrote: I smell a discusion going nowhere. What is the point of teaching a languague? Teach them to program in a paradigm (better, in all of them, and give them the tools to make educated choices about which is better for each context), and choose any language as an *example* of the paradigm. Ah... but beyond design problems, aren't most security problems language-specific abuses and bugs? I'm thinking things like I didn't realize it would let me mix signed and unsigned... I didn't realize it would let me right off the end of the buffer... I didn't realize I had to escape or filter certain characters BB
[SC-L] Secure Coding Themes
So in all the discussions, I think I'm seeing several main themes: -Some holes are design or logic errors (possible in any language) -Some holes are failures to code safely in a given language (language specific; possibly addressable by switching to a safer language) -Some holes are harder to implement in a safer language (library, class...) And I'm sure I've missed a few important ones. Point is, I think in a number of cases, we mix these concepts in the same discussion, and I'm not sure that's always useful. If we're talking about logic problems... you can always get your boolean conditional jump backwards, doesn't matter what language you use. If we're talking about one flavor of secure coding (coding safely in a dangerous language), then that discussion/class neccessarily needs to be very language specific. This problem also extends to things like system APIs, libraries, and so on. I don't know that any significant project can get away from that, regardless of the main language used. If we're talking about secure coding in terms of picking a language that should help us not make whole classes of mistakes, then that's a different discussion. BB
Re: [SC-L] Programming languages used for security
ljknews wrote: 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? BB
Re: [SC-L] Programming languages used for security
ljknews wrote: At 11:38 AM -0700 7/13/04, Blue Boar wrote: ljknews wrote: 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? Return SS$_ACCVIO. So you put in an error handler that catches access ciolation before you try to use the pointer? OK, fair enough. What if the pointer points to memory you own, but not the right kind? I have always been under the impression that raw pointers could always cause you problems. I've assumed that a secure language would have to eliminate that as a type. BB
Re: [SC-L] Application Insecurity --- Who is at Fault?
Michael Silk wrote: See, you are considering 'security' as something extra again. This is not right. It is extra. It's extra time and effort. And extra testing. And extra backtracking and schedule slipping when you realize you blew something. All before it hits beta. Any solution that ends up with us having secure software will neccessarily need to address this step as well as all others. The right answer just might end up being suck it up, and take the resource hit. It might be switch to the language that lends itself to you coding securly at 75% the productivity rate of sloppy coding. I don't know enough about the languages involved to participate in that debate. Strangely enough, for the last year and a half or so, I've been sitting here being QA at a security product company. Doing software right takes extra resources. I are one. Ryan
Re: [SC-L] re: Why Software Will Continue to Be Vulnerable
Bill Cheswick wrote: Probably like many of you, I'm the local friends-and-family computer fixit guy. My father has repeatedly asked why he should care that his computer is totally owned. I've told him that his CPU engine is blowing blue smoke all over the Internet, but that doesn't help. I think people would care if they knew, but they don't know. An outbreak of user-obvious malware might change the equation, but I am not suggesting that someone run the experiment. I think just about the only time I've been called out to lay hands on someone's computer in the last two years (with one exception I can think of), the problem has been malware/spyware. I.e. it had misbehaved to the point where it was untolerable. The browser no longer works, the machine grinds to a halt, the screen goes wonky (screwed up the video drivers), it's popping porn ads at the kids, etc... So my assertion is that much of the malware is very obvious. I'll avoid the temptation to rant at the poor quality of the malware/spyware code itself. I'll also add that I think this is the current big problem for Windows users. Windows itself (XP+) has become reliable *enough*, and the hardware reliable enough (or cheap enough to suffer a forklift upgrade), that it works great... except for the damn malware. The typical reaction I get is incredulity that there are people who sit around all day writing this stuff (malware/spyware.) Any consideration that there's a fault with the OS that allows it in is waaay down the list. So if MS can find a way to make the effects of malware unobservable, then they just about have that market sewn up. Ryan
Re: [SC-L] Bugs and flaws
David Crocker wrote: I don't think this analogy between software development and manufacturing holds. There are no manufacturing defects in software construction For software: A design defect is when you correctly implement what you wanted, and you wanted the wrong thing. A manufacturing defect is when you incorrectly implement what you wanted. BB ___ 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?
Crispin Cowan wrote: Of particular and critical interest at this juncture is segmented memory. Graybeards love segmented memory, and modern Linux kidz hate segmented memory. A close friend has observed to me that 100% of A1 evaluated operating systems (both of them :) used segmented memory. In stark contrast, all modern operating systems use paged memory instead. Apparently there was a movement to hack segments into the Linux kernel a year or so ago, but it was quickly shouted down. ... What? I thought I had the right x86 brain-damage, and knew what segments were. But it doesn't sound like what you are describing. My memory of segments has to do with a painful way to address 64K at a time on 16-bit DOS. As opposed to a nice flat 32-bit (or more) address space. Are you proposing that were I to access a memory address with DS: that I get one set of privs, and if I used ESI: I get a different set? And what does that have to do with paging, which I thought had to do with mapping between physical and logical memory? I'm not trying to flame you Crispin, I'd be willing to bet money that I'm the one who knows less in this area. But I don't think you're explaining what you are getting at well. Please spell it out for me. BB ___ 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] On exploits, hubris, and software security
Gary McGraw wrote: The main thing I wonder is, what do you think? When you have a hot demonstration of an exploit, how do you responsibly release it? What role do such demonstrations play in moving software security forward? To pick one extreme, I believe there are times when intentionally blindsiding a vendor is appropriate: http://ryanlrussell.blogspot.com/2006/11/you-want-mac-wireless-bugs.html BB ___ 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] Disclosure: vulnerability pimps? or super heroes?
J. M. Seitz wrote: On a related note, does anyone have an example where Company A was disclosing vulnerabilities about competing Company B's product and got into trouble over it? Is this something that could be litigated? In fact, Tom Ptacek found a hole in one of Marcus' products while working for a competitor. I suspect Tom reported it properly, though. This research pissed MJR off to no end, which he made clear at one Black Hat talk he gave, with Tom standing at the back of the room. I suspect this was a key point in MJR's life when his code got touched in an inappropriate way, and has led to his current level of curmudgeonry. Or, for a more contemporary example, witness Symantec researchers looking for holes in just about everything. I fail to see any merit for a legitimate lawsuit. Of course, in the US, you can sue whomever you please. BB ___ 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] Disclosure: vulnerability pimps? or super heroes?
Kenneth Van Wyk wrote: So, I applaud the public disclosure model from the standpoint of consumer advocacy. But, I'm convinced that we need to find a process that better balances the needs of the consumer against the secure software engineering needs. Some patches can't reasonably be produced in the amount of time that the vulnerability pimps give the vendors. From the outside, it looks like the vast majority of the patches take as long as the vendor feels like taking. With a small percentage of vulnerabilities being released with no vendor warning at all. It's relatively unusual that I see bulletins where the researcher releases saying that the vendor took too long, so they are releasing now. But that's just going from memory, I haven't done a proper survey or anything. BB ___ 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)
3APA3A wrote: First, by reading 'crack' I thought lady can recover full message by it's signature. After careful reading she can bruteforce collisions 2000 times faster. Cracking a hash would never mean recovering the full original message, except for possibly messages that were smaller than the number of bits in the hash value. There are an infinite number of messages that all hash to the same value. The best crack you can have for a hash is to be able collide with an existing hash value and be able to choose most of the message contents. BB ___ 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)
3APA3A wrote: I know meaning of 'hash function' term, I wrote few articles on challenge-response authentication and I did few hash functions implementations for hashtables and authentication in FreeRADIUS and 3proxy. Can I claim my right for sarcasm after calling ability to bruteforce 160-bit hash 2000 times faster 'a crack'? Fair enough, your sarcasm tags didn't render properly in my MUA. I was fooled by you stating that the birthday attack would be 150 bits. BB ___ 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)
My understanding that the kind of birthday attack under discussion would start at 80-bits if SHA-1 (at 160-bits) were 100% secure. The attack under discussion is reported to reduce that to the neighborhood of 60-something bits. I am not a mathematician though, so I would be perfectly willing to believe I was wrong about that. BB 3APA3A wrote: Dear Blue Boar, It's not clear if this 'crack' cam be applied to birthday attack. My in-mind computations were: because birthday attack requires ~square root of N computations where bruteforce requires ~N/2, impact of 2000 times N decrease for birthday is ~64 times faster. 64 = 2^6. Because complexity is ~square root of possible combinations, it's equivalent of traditional birthday attack, with 160-(2*6)=148 bits hash (150 is my mistake in in-mind computations). Of cause, since I completely wasted 10 years after obtaining Master degree in Mathematics and 3 years after loosing last pencil I may be completely wrong in computations :) --Wednesday, March 21, 2007, 9:48:55 PM, you wrote to [EMAIL PROTECTED]: BB 3APA3A wrote: I know meaning of 'hash function' term, I wrote few articles on challenge-response authentication and I did few hash functions implementations for hashtables and authentication in FreeRADIUS and 3proxy. Can I claim my right for sarcasm after calling ability to bruteforce 160-bit hash 2000 times faster 'a crack'? BB Fair enough, your sarcasm tags didn't render properly in my MUA. I was BB fooled by you stating that the birthday attack would be 150 bits. BB BB ___ 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] Best practices for encrypting client-side data
Robin Sheat wrote: Basically, I needed to encrypt the on-disk format of some data that is accessed as a seekable file (it's actually a Lucene index, but the details aren't too relevant). The use case for this is to ensure the data is kept private, even if the disk or computer the data is on is taken (it's a network-aware client app, so they log in to the program using a username and password). You go on to describe (I think) crypto operations that take place completely on the client site. What is the relationship between the encrypted data and server client-server communications? * The salt is currently hard-coded. It should be regenerated for every encryption operation in order to make it that much harder (question: should it be a different salt used for every file encrypted by a user, or one salt across all files by that user? Does it matter?) You should have a random salt every time you generate a hash or key. * Is it wise to use the user's password directly, or should that perhaps be used to encrypt a key, and that key used to encrypt the files? This would certainly make changing the password easier, but if that key is ever compromised, it's a bigger issue. You can get a little extra security with an encrypted keyfile for certain attack scenarios if done properly. With your design, if I have only the encrypted file, I can start brute-forcing passwords immediately. Might not be practical, depending on how big the salt is, and whether I got that too. If there's an encrypted keyfile, I have to steal that too, plus I still have the exact same amount of brute forcing to do. So, the decisions depends on whether stealing the encrypted data almost always allows me to steal the keyfile, or if you can do something significant;y better, like having the user store the keyfile on a USB drive or the remote server or something. In order to not have created an irrevocable encryption key, every time the user changes their password, you should create a new encryption key and re-encrypt the data with that key, rendering the old stolen keyfile useless. * The Java crypto system looks like black-magic. I haven't seen many things that talk about how to use it well. How do I know I'm not using it in some vulnerable fashion? I can't help you there. I know nothing about Java's implementation details, nor can I tell if you've created a stream cipher that can be decrypted by XORing with itself or something else silly. Ryan ___ 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. ___
[SC-L] Harvard vs. von Neumann
ljknews wrote: It amazes me that someone in a discussion of software security would point to a page that requires Javascript to be viewed. I'm on a couple of mailing list with Dr. Solly, an early antivirus researcher. he likes to talk about this idea of Grannyx an (hypothetical) operating system for Grannies that just does what they need, doesn't have security problems due to simplicity and missing unneeded features, and doesn't mix data and code. Then I point to the Web. Like it or not, the Web doesn't work right without Javascript now. The world has encoded von Neumann architecture into the standards. Ryan ___ 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
der Mouse wrote: 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. Obviously, I'm oversimplifying. I claim that there are enough web sites that require active content to function right (in other words, that's a big part of the reason they are popular) and that there is a big enough critical mass of users who want to use those that it's going to stay. Or another way to put it: First browser that drops support for Javascript commits market suicide. (Actually, the ratio of people who want flashy website to those who care about disabling Javascript is probably 10,000:1, but I digress.) Ryan ___ 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
Crispin Cowan wrote: Do you suppose it is because of the different techniques researchers use to detect vulnerabilities in source code vs. binary-only code? Or is that a bad assumption because the hax0rs have Microsoft's source code anyway? :-) I'm in the process of hiring an outside firm for security review of the product for the day job. They didn't seem particularly interested in the source, the binaries are sufficient. It appears to me that the distinction between source and object is becoming a bit moot nowadays. Ryan ___ 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] how far we still need to go
William L. Anderson wrote: I am flabbergasted. When I first encountered Unix in 1983 I was taught that you always run as an ordinary user, and only use admin (root) privileges when needed. If OS X developers are running as admin, and building and testing their products as admin, well ... I'm still in shock. And I weep for the species. Are you confusing the Mac specifics? Admin on OS X is not the same as root. Members of the Admin group can elevate privs to do things as the equivalent of root, and the Admin group can write to /Applications. The app in question could improve, of course, but the fact the Admin has so much power and that the first user you create is a member of that group is the fault of OS X. (At least, that's the way it worked not too long ago, Apple does seem to occasionally fix these things over time.) BB ___ 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. ___
