Re: [SC-L] How have you climbed the wall?
Rohit Sethi wrote: Recently I sent a note about the Organic Progression of the Secure SDLC. One of the major points that we raise in that model is the difficulty with Climbing the Wall: Getting the lines of business to commit resource to application/software security. This is one of the most fundamental challenges in building a secure SDLC. We offer some simple high level thoughts and a PPT deck you can use here: http://www.sdelements.com/secure-sdlc/software-security-throughout-life-cycle-9-steps/how-climb-wall/ I'm curious to see what others have have done / seen to climb the wall effectively I can't speak for others--although I think that the BSIMM data bears this out--is that our company formed a separate Application Security team. This team was placed within the IT organization (vs. under Risk Management) and was comprised of staff with extensive and varied application development experience who had a common interest in application security. (Note that this team was formed 11 years ago and for the most part, is still intact. I was the technical lead of this group up until about 6 months ago.) For us, this worked out well. Among the first initiatives of this group was to build a custom proprietary application security library similar in intent to ESAPI (although much less ambitious). We also evaluated several vendor web access management solutions, chose one, and then over the period of the last 8 or 9 years, integrated that that vendor solution with close to 250 applications, both internal and external. For the first several years, we also offered free consulting to internal development groups. I think the keys to the team's success in climbing the wall was that it was placed under the IT organization and it was made up of senior developers who had lots of development experience. (I've always believed it's easier to teach a good developer about security than it is to teach a security person about development.) The later was important because they speak the same lingo as developers and could identify with the obstacles that developers face. It's not perfect, but it seems to have been relatively successful. -kevin --- Kevin W. Wall CenturyLink / Risk Mgmt / Information Security kevin.w...@qwest.comPhone: 614.215.4788 Blog: http://off-the-wall-security.blogspot.com/ There are only 10 types of people in the world...those who can count in binary and those who can't. This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. ___ 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. Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates ___
Re: [SC-L] informIT: software security zombies
Gary McCraw wrote: This month's informIT article covers the zombies: [snip] * Software security defects come in two main flavors—bugs at the implementation level (code) and flaws at the architectural level (design) So, two questions: 1) How is this (software *security* defects) different than any other software defect? It seems to me that these are also 2 main categories of software defects in general. 2) In terms of flavors, where do you see software security defects arising from either incorrect requirements or simply lack of specifications? My experience with #2 is that poor specifications are a major contributor to software security defects, more so even than with software defects in general. That's because generally these specs are usually considered non-functional requirements and they get missed more by systems analysts simply because they are not something that the business wants and therefore they aren't put into the reqts and thus never get built. I'm not talking about the pseudo-PCI-like requirements that says things like making sure that you have no OWASP Top Ten vulnerabilities, but rather actual omission of requirements such as failure to specify that data must be kept confidential, or to access this data requires authorization by a certain role, or that an audit trail must be required for certain actions, etc. I don't see how you can chalk these sorts of defects up to flaws at the architecture level (unless you and I have drastically different views of system architecture). The are outright omissions in the specifications and because they are not there, the application team never even thinks about building in that functionality. Bottom line: I think you are missing a flavor. Thanks, -kevin -- Kevin W. Wall 614.215.4788 Qwest Risk Management / Information Security Team Blog: http://off-the-wall-security.blogspot.com/ The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We *cause* accidents.-- Nathaniel Borenstein, co-creator of MIME This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. ___ 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. Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates ___
Re: [SC-L] Question about HIPAA Compliance in application development
Rohit, You wrote: Has anyone had to deal with the following HIPAA compliance requirements within a custom application before: §164.312(c)(2) Implement electronic mechanisms to corroborate that electronic protected health information has not been altered or destroyed in an unauthorized manner. §164.312(e)(2)(i) Implement security measures to ensure that electronically transmitted electronic protected health information is not improperly modified without detection until disposed of. How have you actually implemented these controls in applications? Have you used a third party tool to do this? Does §164.312(c)(2) simply boil down to sufficient access control? Having never had any practical experience with HIPPA, my take on these sections may be different (read wrong) than others, but the way I read these requirements, they have to do more with ensuring data integrity than *merely* proper access control. If that is their intent, then I would look at access control as providing a necessary, but not sufficient security measure to satisfy these requirements. Consequently, I would think that a mechanism such as HMACs or digital signatures may be appropriate security measures here. -kevin --- Kevin W. Wall CenturyLink / Risk Mgmt / Information Security kevin.w...@qwest.comPhone: 614.215.4788 Blog: http://off-the-wall-security.blogspot.com/ There are only 10 types of people in the world...those who can count in binary and those who can't. This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. ___ 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. Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates ___
Re: [SC-L] Question about HIPAA Compliance in application development
On Tue 4/26/2011 11:13 AM, Rohit Sethi wrote: It sounds like people generally deal with this through techniques outside of the application logic itself such as checksums and/or digital signatures on files / database values that contain protected health information. My initial thought was that databases would offer some kind of integrity check feature and that seems to be the feeling from people on the list as well. First, I think that 'checksums' are not going to meet the HIPPA need. They will allow you to detect ACCIDENTAL data integrity issues such as detecting typos upon data entry, data corrupted by disk errors, etc., but they do NOT allow you to detect DELIBERATE tampering attempts that would affect data integrity. Chances are that any attacker who has the ability to change the data can also re-compute and store the updated checksum. So you need a cryptographically strong mechanism to detect such data integrity issues. Generally, that leaves you with HMACs or digital signatures. (Or store the data encrypted using a cipher mode that also provides authenticity, such as GCM, CCM, etc. Shameless plug: Note that the default configuration for symmetric encryption in ESAPI 2.0 provides authenticity so if you need to encrypt the data anyway, that might be a valid approach for you.) However, *in general*, DBs do not offer this type of protection, especially if there is a concern with a privileged attacker (say a rogue DBA) making unauthorized changes to the database. (Some of the features with packages like Oracle's Transparent Data Encryption may provide this, but generally it is not something that is part of the vanilla DBMS. The data integrity issues that a DBMS addresses are _referential_ integrity, not *content* data integrity.) Has anyone actually implemented this kind of control *within* custom application logic? For example, verifying the integrity of stored protected health data by (for example) checking that a digital signature is valid before displaying it back to the user? I was tech lead on a project that we did this, but it was unrelated to HIPPA. It was a project that dealt with some very sensitive data. The application associated each DB record with an HMAC. The HMAC key was computed by the application, based on a derived key from a Shamir shared secret calculated by signed Shamir shares entered by at least 2 authorized operations personal when the application cluster was initialized. This was done to explicitly prevent the threat of rogue DBAs changing the extremely sensitive data or changing who was authorized to access to that sensitive data. When the data was retrieved from the DB, the HMAC was computed from all the other columns and them compared with the stored HMAC column for that record. If they did not agree, a security exception was logged and thrown. (HMACs were used instead of dsigs because they are so much faster in computing and nonrepudiation was not an issue.) If you are not concerned with rogue DBAs as a threat source, this logic could be placed in the DB itself using triggers and stored procedures (or just stored procedures if you don't have an legacy code base and you somehow prevent direct inserts / updates). If you are interested in pursuing that angle, you may want to reference Kevin Kenan's book, _Cryptography in the Database: The Last Line of Defense_. Finally--and this is probably obvious to most SC-L readers--you need to ensure that your application has no SQLi vulnerabilities that would allow data to be altered in an unauthorized manner. If you don't, then the HMAC or dsig or whatever you are using to ensure data integrity will simply be inserted / updated by your application or DB code like it would for an otherwise legitimate authorized attempt. HTH, -kevin -- Kevin W. Wall CenturyLink / Risk Mgmt / Information Security kevin.w...@qwest.comPhone: 614.215.4788 Blog: http://off-the-wall-security.blogspot.com/ The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents.-- Nathaniel Borenstein, co-creator of MIME This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. ___ 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. Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
Re: [SC-L] Java DOS
On Feb 15, 2011, at 12:06 AM, Chris Schmidt chrisisb...@gmail.com wrote: On Feb 14, 2011, at 8:57 AM, Wall, Kevin kevin.w...@qwest.com wrote: [snip[ So on a somewhat related note, does anyone have any idea as to how common it is for application developers to call ServletRequest.getLocale() or ServletRequest.getLocales() for Tomcat applications? Just curious. I'm sure it's a lot more common than developers using double-precision floating point in their applications (with the possible exception within the scientific computing community). I would assume just about any app with a shopping cart does. This is of course compounded by libraries like struts and spring mvc that autobind your form variables for you. Use a form with a double in it and your boned. Good point about things like Spring and Struts. Hadn't thought of those cases. OTOH, if I were implementing a shopping cart, I'd write a special Currency class and there probably use Float.parseFloat() rather than Double.parseDouble() [unless I were a bank or otherwise had to compute interest], and hopefully Float does not have similar issues. -kevin -- Kevin W. Wall 614.215.4788 Qwest Risk Management / Information Security Team The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We *cause* accidents.-- Nathaniel Borenstein, co-creator of MIME From: Chris Schmidt [chrisisb...@gmail.com] Sent: Tuesday, February 15, 2011 12:06 AM To: Wall, Kevin Cc: Jim Manico; Rafal Los; sc-l@securecoding.org Subject: Re: [SC-L] Java DOS This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. ___ 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. Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates ___
Re: [SC-L] Java DOS
Jim Manico wrote... Rafal, It's not that tough to blacklist this vuln while you are waiting for your team to patch your JVM (IBM and other JVM's have not even patched yet). I've seen three generations of this filter already. Walk with me, Rafal and I'll show you. :) 1) Generation 1 WAF rule (reject one number only) This mod security rule only blocks a small portion of the DOSable range. The mod security team is working to improve this now (no disrespect meant at all!) SecRule ARGS|REQUEST_HEADERS @contains 2.2250738585072012e-308 phase:2,block,msg:'Java Floating Point DoS Attack',tag:'CVE-2010-4476' Reference: http://mobile.twitter.com/modsecurity/status/35734652652093441 Depending how when the exponent conversion is done, this mod_security rule may be completely ineffective. For example, if an attacker can write this floating point # as the equivalent 22.250738585072012e-309 (which note, I have not tested), then the test above is invalid. I presumed that this was why Adobe's blacklist *first* removed the decimal point. Adobe's blacklist could be generalized a bit to cover appropriate ranges with a regular expression, but I agree wholeheartedly with you that what you dubbed as the Chess Defense (I like it) is the best approach short of getting a fix from the vendor of your JRE. So on a somewhat related note, does anyone have any idea as to how common it is for application developers to call ServletRequest.getLocale() or ServletRequest.getLocales() for Tomcat applications? Just curious. I'm sure it's a lot more common than developers using double-precision floating point in their applications (with the possible exception within the scientific computing community). -kevin --- Kevin W. Wall Qwest Risk Mgmt / Information Security kevin.w...@qwest.comPhone: 614.215.4788 It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration - Edsger Dijkstra, How do we tell truths that matter? http://www.cs.utexas.edu/~EWD/transcriptions/EWD04xx/EWD498.html This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. ___ 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. Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates ___
Re: [SC-L] Java: the next platform-independent target
On October 20, 2010, Benjamin Tomhave wrote: snip If I understand this all correctly (never a safe bet), it seems these are actual attacks on Java, not on coding with Java. Ergo, this isn't something ESAPI can fix, but rather fundamental problems. What do you think? Overblown? Legit? Solutions forthcoming? snip In a private, off-list email to Ben Tomhave, Kevin Wall incorrectly speculated in a reply: W/out having read this at all (will do later, when I get home), I'd just say that there's a lot of safety nets built into Java / JavaEE, but most (99%) of development teams don't use them. Examples (from most to least important IMO) are: Java security manager and appropriately restrictive security policy Sealed jars Signed jars If you are running w/out a security manager, you are really working w/out a safety net. I know that Dinis Cruz and I have had this conversation a few times and I think we are both in agreement on that matter. Ben, When you first referenced these URLs, I thought these were about server-side exploits, but reading through these, it appears that most of them are client-side exploits that are attacked using malware applets. Since applets do use a Java security manager, that shoots my original theory I mentioned below. (I would stand behind this conclusion for server-side exploits though.) So, you are right about ESAPI not helping here as one is downloading and running untrusted code in the first place and it's doubtful that an attacker is going to use ESAPI to protect their victims. :) However, I think I reached a different conclusion then you did. It appears that the major issue here is users are not updating their Java installations either because either they are not aware it is installed to start with or perhaps because automatic Java updates are disabled on not installed correctly. I think the solution for this problem (which, IMO, is unlikely, at least in the near-term future) is that Windows Update needs to include *all* the software (or at least all the common software that adheres to some common packaging format) running under a Windows OS. Most Linux systems already do this. For instance on Ubuntu or OpenSUSE, if I wish to update Java or Adobe Flash or Acrobat, I don't do anything different then when I'd update something that is provided by the vendor. Frankly, the fact that that Windows Update doesn't do this was one major reason why I've replaced all my Windows instances with various Linux installs. I used to run Secunia PSI to scan my Windows system, but even though I knew *what* to patch, doing so was way too painful. I can only imagine that the typical PC user is much less diligent about keeping their system patched that I am, which would explain a lot. Java is on most systems and rarely is patched, ergo, recipe for disaster. So my conclusion is that these findings say more about the fact that these systems are not being patched than it is a poor reflection on the quality of Java. (The report indicates that this enormous jump in the number of exploits is due to the fact that three particular vulnerabilities are being constantly exploited and that These vulnerabilities have been patched for a while, but the problem is that users fail to update Java on their system.) Given the slant of posts to this list, I originally thought these reports were about JavaEE app servers being vulnerable. So, my bad for jumping to conclusions, but I think my new conclusion is that this is not so much much an issue with Java (the language + VM) as it is with the way that Java Update (as delivered by Sun / Oracle) sucks. Regards, -kevin -- Kevin W. Wall 614.215.4788Application Security Team / Qwest IT The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents.-- Nathaniel Borenstein, co-creator of MIME This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. ___ 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. Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates ___
Re: [SC-L] Solution for man-in-the-browser
On Sep 10, 2010, at 5:34 PM, smurray1 smurr...@nycap.rr.com wrote: Hello, I have been discussing an issue with an organization that is having an issue with malware on it's customer's clients that is intercepting user credentials and using them to create fraudulent transactions. (man-in-the-browser type attacks similar to what Zeus and other trojans are capable of). I told them that they should be using a shared secret between the user and the system to use as an input to HMAC to create a MAC for the form for the critical transaction. I see it working like this. The form that is used for the critical transaction would have either a java object or javascript that, after the user fills the field and the presses the submit button: 1) Accepts a single use shared secret from the user. ...deleted... Jim Manico responded: I do not think this will work. Once your browser is trojaned, it's game over. The Trojan has the capability to just sit in your browser and wait for the user to log in. (Trojans do not need to steal credentials to cause harm). Once the user has logged on, the Trojan can simulate any user activity such as requesting and submitting forms, circumventing CSRF tokens and other web app defenses. Jim is absolutely correct. You are better off spending time removing all the malware and securing your machines properly, trying to educate your users, etc. You may also want to add AV scanning during the web browsing sessions if you don't already support that. Besides, once your browser is trojaned, there is no shared secret, or more accurately, you would also be sharing your secret with the malware which obviously would not do you any good. Once the browser endpoint is compromised, NOTHING sent from it can be trusted any longer. For instance, since TLS provides only point-to-point encryption, malware running in the browser can read plaintext and insert data at will. Bottom line, don't waste your development $$ on a problem that cannot be fixed in this manner. -kevin -- Kevin W. Wall 614.215.4788Application Security Team / Qwest IT The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents.-- Nathaniel Borenstein, co-creator of MIME This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. ___ 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. Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates ___
Re: [SC-L] any one a CSSLP is it worth it?
Gary McGraw wrote... Way back on May 9, 2007 I wrote my thoughts about certifications like these down. The article, called Certifiable was published by darkreading: http://www.darkreading.com/security/app-security/showArticle.jhtml?articleID=208803630 I just reread your Dark Reading post and I must say I agree with it almost 100%. The only part where I disagree with it is where you wrote: The multiple choice test itself is one of the problems. I have discussed the idea of using multiple choice to discriminate knowledgeable developers from clueless developers (like the SANS test does) with many professors of computer science. Not one of them thought it was possible. I do think it is possible to separate the clueful from the clueless using multiple choice if you cheat. Here's how you do it. You write up your question and then list 4 or 5 INCORRECT answers and NO CORRECT answers. The clueless ones are the ones who just answer the question with one of the possible choices. The clueful ones are the ones who come up and argue with you that there is no correct answer listed. ;-) -kevin --- Kevin W. Wall Qwest Information Technology, Inc. kevin.w...@qwest.comPhone: 614.215.4788 It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration - Edsger Dijkstra, How do we tell truths that matter? http://www.cs.utexas.edu/~EWD/transcriptions/EWD04xx/EWD498.html This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. ___ 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. Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates ___
Re: [SC-L] [WEB SECURITY] RE: How to stop hackers at the root cause
Jeremiah Heller writes... do security professionals really want to wipe hacking activity from the planet? sounds like poor job security to me. Even though I've been involved in software security for the past dozen years or so, I still think this is a laudable goal, albeit a completely unrealistic one. I for one, would be completely happy to go back to software development / systems programming if all the security issues completely disappeared. But unfortunately, I don't think we ever have to worry about this happening. the drive for survival seems key. i think that when the survival of many is perceived as threatened, then 'bad hacking' will be addressed on a scale which will contain it to the point that slavery is contained today... after all don't hackers simply 'enslave' other computers? j/k And of course, that is a good thing. After all, once the first sentient AI takes control of all the world's computers to subjugate all humanity, we have to have a way to fight back. Evil h40rs to the rescue! ;-) until then it seems that educating people on how these things /work/ is the best strategy. eventually we will reach the point where firewalls and trojan-hunting are as common as changing your oil and painting a house. I agree. Even though one risks ending up with smarter criminals, by and large if one addresses the poverty issues most people ultimately seem to make the right decisions in the best interests of society. I think for many, once their curiosity is satisfied and the novelty wears off they put these skills to good use. At least it seems to me a risk worth taking. first we should probably unravel the electron... and perhaps the biological effects of all of these radio waves bouncing around our tiny globe... don't get me wrong, i like my microwaves, they give me warm fuzzy feelings:)o Jeremiah, you do know that you're not supposed to stick your *head* in the microwave, don't you? No wonder you're getting the warm fuzzies. :) -kevin --- Kevin W. Wall Qwest Information Technology, Inc. kevin.w...@qwest.comPhone: 614.215.4788 It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration - Edsger Dijkstra, How do we tell truths that matter? http://www.cs.utexas.edu/~EWD/transcriptions/EWD04xx/EWD498.html This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. ___ 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. Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates ___
Re: [SC-L] any one a CSSLP is it worth it?
Dana Epp wrote: Not sure that would work either though. Dana, My comment was meant tongue-in-cheek. Guess I used the wrong emoticon. Figured that ';-)' would work 'cuz I never can remember the one for tongue-in-cheek. I've seen several variations of the latter... :-? :-Q :-J -) Take your pick. Good in depth analysis though. Seriously. And I agree with you completely. In my experience as an adjunct faculty member teaching a master's level Computer Security course (based in part on the McGraw/Viega book as well as Ross Anderson's _Security Engineering_) for 6 yrs, I came to the conclusion that multiple guess (as I call them) alone only proves how well someone memorizes something, at best, or how clueless people are (if they get incorrect answers) at worst. I would argue that most of academia it is unsuited for discerning cluefulness the the real world. Over the course of 30+ yrs in IT (yes, I am an old fart!), I've seen all too many people that exceled in academia but were miserable disappointments in industry. In fact, to that end, quality guru Demming is rumored to have said about (then) ATT Bell Labs: Bell Labs only hires the top 10% of graduatesc...and they deserve what they get! There is no substitute for real experience. -kevin --- Kevin W. Wall Qwest Information Technology, Inc. kevin.w...@qwest.comPhone: 614.215.4788 It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration - Edsger Dijkstra, How do we tell truths that matter? http://www.cs.utexas.edu/~EWD/transcriptions/EWD04xx/EWD498.html This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. ___ 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. Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates ___
Re: [SC-L] seeking hard numbers of bug fixes...
Benjamin Tomhave wrote: ... we're looking for hard research or numbers that covers the cost to catch bugs in code pre-launch and post-launch. The notion being that the organization saves itself money if it does a reasonable amount of QA (and security testing) up front vs trying to chase things down after they've been identified (and possibly exploited). Ben, Not sure if this is what you are looking for or not, but back in the mid- to late-1980s or so, John Musa, a DMTS at Bell Labs, wrote up a couple of papers that showed this data, although this was in the more general context of software quality assurance and not specific to security testing. I'm pretty sure that Musa published something in either one of the ACM or IEEE CS journals and included some hard data, collected from a bunch of (then ATT) Bell Labs projects. IIRC, the main finding was something like the cost was ~100 times more to catch and correct a bug during the normal design / coding phase than it was to catch / correct it after post-deployment. Can't help you much more than that. I'm surprised I remembered that much! :) -kevin --- Kevin W. Wall Qwest Information Technology, Inc. kevin.w...@qwest.comPhone: 614.215.4788 It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration - Edsger Dijkstra, How do we tell truths that matter? http://www.cs.utexas.edu/~EWD/transcriptions/EWD04xx/EWD498.html This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. ___ 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] BSIMM update (informIT)
On Thu, 28 Jan 2010 10:34:30 -0500, Gary McGraw wrote: Among other things, David [Rice] and I discussed the difference between descriptive models like BSIMM and prescriptive models which purport to tell you what you should do. I just wrote an article about that for informIT. The title is Cargo Cult Computer Security: Why we need more description and less prescription. http://www.informit.com/articles/article.aspx?p=1562220 First, let me say that I have been the team lead of a small Software Security Group (specifically, an Application Security team) at a large telecom company for the past 11 years, so I am writing this from an SSG practitioner's perspective. Second, let me say that I appreciate descriptive holistic approaches to security such as BSIMM and OWASP's OpenSAMM. I think they are much needed, though seldom heeded. Which brings me to my third point. In my 11 years of experience working on this SSG, it is very rare that application development teams are looking for a _descriptive_ approach. Almost always, they are looking for a _prescriptive_ one. They want specific solutions to specific problems, not some general formula to an approach that will make them more secure. To those application development teams, something like OWASP's ESAPI is much more valuable than something like BSIMM or OpenSAMM. In fact, I you confirm that you BSIMM research would indicate that many companies' SSGs have developed their own proprietary security APIs for use by their application development teams. Therefore, to that end, I would not say we need less _prescriptive_ and more _descriptive_ approaches. Both are useful and ideally should go together like hand and glove. (To that end, I also ask that you overlook some of my somewhat overzealous ESAPI developer colleagues who in the past made claims that ESAPI was the greatest thing since sliced beer. While I am an ardent ESAPI supporter and contributor, I proclaim it will *NOT* solve our pandemic security issues alone, nor for the record will it solve world hunger. ;-) I suspect that this apparent dichotomy in our perception of the usefulness of the prescriptive vs. descriptive approaches is explained in part by the different audiences with whom we associate. Hang out with VPs, CSOs, and executive directors and they likely are looking for advice on an SSDLC or broad direction to cover their specifically identified security gaps. However, in the trenches--where my team works--they want specifics. They ask us How can you help us to eliminate our specific XSS or CSRF issues?, Can you provide us with a secure SSO solution that is compliant with both corporate information security policies and regulatory compliance?, etc. If our SSG were to hand them something like BSIMM, they would come away telling their management that we didn't help them at all. This brings me to my fourth, and likely most controversial point. Despite the interesting historical story about Feynman, I question whether BSIMM is really scientific as the BSIMM community claims. I would contend that we are only fooling ourselves if we claim otherwise. And while BSIMM is a refreshing approach opposed to the traditional FUD modus operandi taken by most security vendors hyping their security products, I would argue that BSIMM is no more scientific than the those who gather common quality metrics of counting defects/KLOC. Certainly there is some correlation there, but cause and effect relationships are far from obvious and seem to have little predictive accuracy. Sure, BSIMM _looks_ scientific on the outside, but simply collecting specific quantifiable data alone does not make something a scientific endeavor. Yes, it is a start, but we've been collecting quantifiable data for decades on things like software defects and I would contend BSIMM is no more scientific than those efforts. Is BSIMM moving in the right direction? I think so. But BSIMM is no more scientific than most of the other areas of computer science. To study something scientifically goes _beyond_ simply gathering observable and measurable evidence. Not only does data needs to be collected, but it also needs to be tested against a hypotheses that offers a tentative *explanation* of the observed phenomena; i.e., the hypotheses should offer some predictive value. Furthermore, the steps of the experiment must be _repeatable_, not just by those currently involved in the attempted scientific endeavor, but by *anyone* who would care to repeat the experiment. If the steps are not repeatable, then any predictive value of the study is lost. While I am certainly not privy to the exact method used to arrive at the BSIMM data (I have read through the BSIMM Begin survey, but have not been involved in a full BSIMM assessment), I would contend that the process is not repeatable to the necessary degree required by science. In fact, I would claim in most organizations, you could take any group of BSIMM interviewers and have them question different
Re: [SC-L] 2010 bug hits millions of Germans | World news | The Guardian
Stephen Craig Evans wrote... Looks like there's another one: Symantec Y2K10 Date Stamp Bug Hits Endpoint Protection Manager http://www.eweek.com/c/a/Security/Symantec-Y2K10-Date-Stamp-Bu g-Hits-Endpoint-Protection-Manager-472518/? kc=EWKNLSTE01072010STR1 I am VERY curious to learn how these happened... Only using the last digit of the year? Hard for me to believe. Maybe it's in a single API and somebody tried to be too clever with some bit-shifting. Just speculation, but perhaps all these systems are using the fixed window technique to address these two digit year fields common on credit cards. Depending on the pivot point year that is chosen determines whether a 2 digit year field belongs to one century or the other. This could just be a carry over from the Y2K fixes and the rather poor choice for a pivot point. I worked next to a person who did some Y2K fixes for lots of mainframes back in 1998-99, and he said that using 'windowing' to address this was a pretty common technique because companies did not want to expand all their databases and forms, etc. to allow for 4 digits. For example, if 1980 was chosen as the pivot year, then 2 digit years 80 through 99 would be assigned '1900' as the century and 00 through 79 would be assigned '2000' as the century. So perhaps 1910 was chosen as the pivot year (if DOB was a consideration, that would not be all that unreasonable) so that 10 through 99 is interpreted as 1900s and 00 through 09 was considered as 2000 something. So we hit 2010 and a credit card has a 2 digit year for it's expiration or transaction date or whatever, and all of a sudden 01/10 or 01/07/10 is interpreted as 1910. Usually using such a fixed windowing technique (there is also a sliding window technique that was a more expensive fix) was only considered a stop-gap measure with most organizations fixing things for real before the pivot year gave them trouble. But we all know about how good intentions work...or not. Anyhow, like I said, this is only a GUESS of what might be going on. I have no hard data to back it up. -kevin --- Kevin W. Wall Qwest Information Technology, Inc. kevin.w...@qwest.comPhone: 614.215.4788 It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration - Edsger Dijkstra, How do we tell truths that matter? http://www.cs.utexas.edu/~EWD/transcriptions/EWD04xx/EWD498.html This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. ___ 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] 2010 bug hits millions of Germans | World news | The Guardian
Larry Kilgallen wrote... At 10:43 AM -0600 1/7/10, Stephen Craig Evans wrote: I am VERY curious to learn how these happened... Only using the last digit of the year? Hard for me to believe. Maybe it's in a single API and somebody tried to be too clever with some bit-shifting. My wife says that in the lead-up to the year 2000 she caught some programmers fixing Y2K bugs by continuing to store year numbers in two digits and then just prefixing output with 19 if the value was greater than some two digit number and prefixing output with 20 if the value was less than or equal to that two digit number. Never underestimate programmer creativity. Never overestimate programmer precision. While I never fixed any Y2K problems I worked next to someone who did for about 6 months. What you refer to is pretty much what I mentioned as the fixed window technique that was very common to those developers who were addressing the problems at the time. IIRC, it was a particularly popular approach for those who waited until the last moment to address Y2K issues in there systems because it still allowed for 2 digit year fields in all their forms and databases and output. --- Kevin W. Wall Qwest Information Technology, Inc. kevin.w...@qwest.comPhone: 614.215.4788 It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration - Edsger Dijkstra, How do we tell truths that matter? http://www.cs.utexas.edu/~EWD/transcriptions/EWD04xx/EWD498.html This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. ___ 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] Provably correct microkernel (seL4)
Steve Christy wrote... I wonder what would happen if somebody offered $1 to the first applied researcher to find a fault or security error. According to http://ertos.nicta.com.au/research/l4.verified/proof.pml, buffer overflows, memory leaks, and other issues are not present. Maybe people would give up if they don't gain some quick results, but it seems like you'd want to sanity-check the claims using alternate techniques. I was actually wondering how they could make that statement unless they can somehow ensure that other components running in kernel mode (e.g., maybe devices doing DMA or device drivers, etc.) can't overwrite the microkernel's memory address space. It's been 20+ years since I've done any kernel hacking, but back in the day, doing something like that with the MMU I think would have been prohibitively expensive in terms of resources. I've not read through the formal proof (figuring I probably wouldn't understand most of it anyhow; it's been 30+ years since my last math class so those brain cells are a bit crusty ;-) but maybe that was one of the caveats that Colin Cassidy referred to. In the real world though, that doesn't seem like a very reasonable assumption. Maybe today's MMUs support this somehow or perhaps the seL4 microkernel runs in kernel mode and the rest of the OS and any DMA devices run in a different address space such as a supervisory mode. Can anyone who has read the nitty-gritty details explain it to someone whose brain cells in these areas have suffered significant bit rot? -kevin -- Kevin W. Wall 614.215.4788Application Security Team / Qwest IT The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents.-- Nathaniel Borenstein, co-creator of MIME ___ 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] Provably correct microkernel (seL4)
Thought there might be several on this list who might appreciate this, at least from a theoretical perspective but had not seen it. (Especially Larry Kilgallen, although he's probably already seen it. :) In http://www.unsw.edu.au/news/pad/articles/2009/sep/microkernel_breakthrough.html, Professor Gernot Heiser, the John Lions Chair in Computer Science in the School of Computer Science and Engineering and a senior principal researcher with NICTA, said for the first time a team had been able to prove with mathematical rigour that an operating-system kernel -- the code at the heart of any computer or microprocessor -- was 100 per cent bug-free and therefore immune to crashes and failures. In a new item at NICTA http://nicta.com.au/news/current/world-first_research_breakthrough_promises_safety-critical_software_of_unprecedented_reliability it mentions this proof was the effort of 6 people over 5 years (not quite sure if it was full-time) and that They have successfully verified 7,500 lines of C code [there's the problem! -kww] and proved over 10,000 intermediate theorems in over 200,000 lines of formal proof. The proof is machine-checked using the interactive theorem-proving program Isabelle. Also the same site mentions: The scientific paper describing this research will appear in the 22nd ACM Symposium on Operating Systems Principles (SOSP) http://www.sigops.org/sosp/sosp09/. Further details about NICTA's L4.verified research project can be found at http://ertos.nicta.com.au/research/l4.verified/. My $.02... I don't think this approach is going to catch on anytime soon. Spending 30 or so staff years verifying a 7500 line C program is not going to be seen as cost effective by most real-world managers. But interesting research nonetheless. -kevin --- Kevin W. Wall Qwest Information Technology, Inc. kevin.w...@qwest.comPhone: 614.215.4788 It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration - Edsger Dijkstra, How do we tell truths that matter? http://www.cs.utexas.edu/~EWD/transcriptions/EWD04xx/EWD498.html ___ 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] Where Does Secure Coding Belong In the Curriculum?
Ben Tomhave wrote: Wall, Kevin wrote: I don't mean to split hairs here, but I think fundamental concept vs intermediate-to-advanced concept is a red herring. In your case of you teaching a 1 yr old toddler, NO is about the only thing they understand at this point. That doesn't imply that concepts like street are intermediate-to-advanced. It's all a matter of perspective. If you are talking to someone with a Ph.D. in physics about partial differential equations, PDEs *are* a fundamental concept at that level (and much earlier in fact). The point is, not to argue semantics, but rather to teach LEVEL-APPROPRIATE concepts. I think you do mean to split hairs, and I think you're right to do so. Context is very important. For example, all this talk about where to fit secure coding into the curriculum is great, but it also ignores the very arge population of self-taught coders out there, as well as those who learn their craft in a setting other than a college or university. Ergo, it still seems like we're talking at ends about an issue that, while important, is still only at best a partial solution. Of course it's only a partial solution and I think you raise some very valid concerns. Normally, I wouldn't consider the self-taught in a discussion of where does secure coding belong in the CURRICULUM, but we can't ignore that 800 lb gorilla either. That of course is a much harder challenge. I suppose in some sense we should expect / hope that these same concepts that we've been discussing are addressed in the numerous books, periodicals, web sites, etc. where most of this learning happens. But that's probably much more difficult sitation to change...more of a wild, wild west in comparison to academia. Ultimately, most sane people act in accordance with that they are rewarded for doing things correct and disciplined for doing wrong. In academia, we can do this with grades for students, pay and/or tenure or other perks for professors / lecturers, etc. But once we get into books and magazines realm, we have to look for the publishers to reward / discipline appropriately and IMO they don't necessarily have the same drivers as to academia. Many publishers seem to be more concerned with just making a quick $$ rather than being accurate or thoroughly training people to do things correctly. (How else can you explain books explain tabloids, unless you subscribe to the MiB theory. And IMHO, there are plenty of tabloid-like publishers writing books in the programming field, but I digress.) Getting back to my point, you don't have that less control for someone putting up their own educational web pages that profess to teach programming to which many of the self-educated seem to rely on. There are plenty good ones, but most I've seen seem to be oblivious to secure coding practice (w/ exception of security-related sites such as OWASP, etc.) So it's only things like reputation, and ultimately market pressures that force any corrective actions in regards to publishers of written and web material. Add to that the problem that BECAUSE these people are self-taught, the generally don't have someone to provide guidance to separate the wheat from the chaff like instructors hopefully do with their students. But if self-taught programmers are the 800 pound gorilla, then corporate business is the 4 ton elephant. If anything, I would say that addressing the pressures that seem to be on corporate programmers that come to bear _against_ secure coding practice (although unintentionally) is the MUCH BIGGER problem. (Most people go into CS to move into industry after all, not to stay and teach/research in academia.) Most businesses rate secure code as a very low need and to emphasize time-to-market (which presumably has a direct correlation to market share, or so we've been told) over everything else. IMHO, that leads to more slip-shod code than any other single factor. Adding defensive code to make it more robust against attacks takes additional time, which on large projects can be quite significant. To make matters worse, many IT shops in the USA seem to reward the how fast can you crank out code (no matter how insecure) over the how good of quality do you deliver mentality. What is rewarded in IT shops is quantity of LOC cranked out each week (wrongly widely perceived as equivalent to productivity) over quality (less buggy code, which I believe correlates well less vulnerabilities). I have no sour grapes here--never wanted to move into management--yet over my 30+ years in industry (mostly telecom), I've seen the fast get rewarded, transfer to another project before things crash-and-burn, and then go on to get promoted to some management position. And then they continue to act this was as managers because that's what got them there. Let's face it, the IT industry in the USA is one huge dysfunctional family. So, I think *that's* why we've been focusing on formal education. There is a chance, a glimmer
Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?
James McGovern wrote... - Taking this one step further, how can we convince professors who don't teach secure coding to not accept insecure code from their students. Professors seed the students thinking by accepting anything that barely works at the last minute. Universities need to be consistent amongst their own teaching/thinking. Well, actually, I think that what Matt Bishop wrote in his response to Benjamin Tomhave is the key: But in introductory classes, I tend to focus on what I am calling robust above; when I teach software security, I focus on both, as I consider robustness part of security. By the way, you can do this very effectively in a beginning programming class. When I taught Python, as soon as the students got to basic structures like control loops (for which they had to do simple reading), I showed them how to catch exceptions so that they could handle input errors. When they did functions, we went into exceptions in more detail. They were told that if they didn't handle exceptions in their assignments, they would lose points -- and the graders gave inputs that would force exceptions to check that they did. Most people got it quickly. That is, Matt suggested a direct reward / punishment. Specifically, if the students don't account for bad input via exceptions or some other suitable mechanism, the simply loose points. Matt's right. If it boils down to grades, most students will get it, and fast. And whether we call this secure-coding, robustness, or simply correctness, it's a start. I think that too many people when they hear that we need to start teaching security at every level of CS are thinking of more complicated things like encryption, authentication protocols, Bell-LaPadula, etc. but I don't think that was where the thrust of this thread was leading. -kevin --- Kevin W. Wall Qwest Information Technology, Inc. kevin.w...@qwest.comPhone: 614.215.4788 It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration - Edsger Dijkstra, How do we tell truths that matter? http://www.cs.utexas.edu/~EWD/transcriptions/EWD04xx/EWD498.html ___ 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] Where Does Secure Coding Belong In the Curriculum?
Brad Andrews writes... I had proofs in junior high Geometry too, though I do not recall using them outside that class. I went all the way through differential equations, matrix algebra and probability/statistics and I don't recall much focus on proofs. This was in the early 1980s in a good school (Illinois), so it wasn't just modern teaching methods that were too blame. I am not sure that the proofs were all that useful for understanding some things either, though the logic they taught has value that I missed a bit of since I did hit some modern techniques. This may be heading slightly OT, but I don't think your experience is really that unusual. My BS was a double major in math and physics and my MS was in CS. We used proofs in most of my math classes, many of my physics classes, and several of my CS classes. Besides the frequency, what varied in each of these was the level of rigor expected. The proofs in math were extremely rigorous, the ones in physics less so, and the ones in most of my CS classes would have been classified as only so much hand waving if they would have been done in my math classes. But an important thing to note in all of these courses was, with the exception of very few advanced (senior grad level) math classes such as advanced calculus and abstract algebra and number theory, the use of 'proofs' wasn't the end, but only a means to the end. But still 'proofs' were utilized throughout much of this very diverse coursework to add to the rigor of the logic and presumably to reinforce understanding and learning. In the same way, I think that 'security' (or 'robustness' or 'correctness' or whatever you wish to call it) needs to be CONSISTENTLY blended into the college and possibly even high school CS curriculum so some element of it is touched upon in each of the classes and as one progresses it is discussed more and more. So just as 'proofs' are sprinkled into math, physics, CS, etc. we need to sprinkle in basic security / robustness concepts such as: + An understanding of what input may be 'trusted' and what inputs cannot be trusted leading to the concept of trust boundaries. + The concept of correctness extends merely past handling 'correct' input and needs to somehow gracefully handle incorrect input as well. + Understanding the concept of risk, eventually leading to an understanding of risk analysis in upper level CS courses + Having an adversarial testing mindset, always thinking how can I 'break' this program or system?. (BTW, sad to say, this has probably been the hardest thing to teach my colleagues. Some of them seem to get it, and some of them never do.) There are probably others--this is by no means a complete list--but we need to emphasize that to those instructing CS that this is not going to take up a significant portion of their coursework nor require a significant amount of time or effort on there part. Rather it needs to be folded into the mix as appropriate. I think back to my days in elementary mathematics. I recall learning at a very early age, when learning division, that you can't divide by 0. The explanation given by the teach wasn't in depth, it was more like you are just not permitted to do that, or occasionally it's undefined without telling us WHY it's undefined. In a similar manner, we can teach don't blindly accept unchecked input, etc. And then if that is reinforced in the grading process I do think it will come through. Surely if we could just do that much, it would be a good start. But my observation, based on my CS colleagues that I've taught with and before that, the CS courses that I've taken at the graduate level, is that other than the obligatory half hour mention of security in my operating systems course, I can barely recall it ever even coming up. And I also seldom recall that instructors would every toss your programs truly malformed input either. By comparison, when I had an opportunity to teach a masters level CS course on distributed systems (the Tannenbaum book), I tossed in matters of security throughout, not just in the chapters about security. Of course, I don't think until we got to the chapters about security that the students realized that's what I was teaching them, but that's OK too. The subliminal methods sometimes work as well. -kevin -- Kevin W. Wall 614.215.4788Application Security Team / Qwest IT The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents.-- Nathaniel Borenstein, co-creator of MIME ___ 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,
Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?
Karen Goertzel wrote... I'm more devious. I think what needs to happen is that we need to redefine what we mean by functionally correct or quality code. If determination of functional correctness were extended from must operate as specified under expected conditions to must operate as specified under all conditions, functional correctness would necessarily require security, safety, fault tolerance, and all those other good things that make software dependable instead of just correct. Except, unfortunately, as an industry / profession, we can't even get the far-simpler (IMO) _functional correctness_ right let alone (so-called) non-functional issues such as security, safety, fault tolerance, etc. (Mathematical rigor and proof-of-correctness aside, but in many [most?] cases that's not practical and even if it were, most programmers' brains turn to mathematical mush whenever they see any kind of correctness proof. Meaning that it ain't going to happen if it requires thinking. ;-) In some regard, I think this holds things back. If we don't do a good job testing that the software does all that it's supposed to do under *ideal* conditions, how are we ever to expect developers and testers to test to make sure that the software doesn't do additional things that it's NOT supposed to do under less than ideal conditions. There's a reason why Ross Anderson and Roger Needham talked about Programming Satan's Computer (see http://www.cl.cam.ac.uk/~rja14/Papers/satan.pdf). [Yes, I 'm aware that paper was about the correctness of distributed cryptographic protocols, but I think both Anderson and Needham would agree that the term Programming Satan's Computer applies more generally than just to that narrow aspect of security.] Not that I'm advocating of giving up, mind you. If the battle seems hopeless, perhaps we would see more progress if we were to address secure programming issues simply as a related aspect of program correctness. Why? Because the development community seems to be more willing to address those things. (Obviously, part of that is that many programming flaws are rather tangible and something that casual users can experience. Yeah! That's the ticket. Let's teach the general populace how to hack into systems! Pass out free You've been pwnd! T-shirts with every successful pwnage. Now *THAT* would be devious. ;-) -kevin --- Kevin W. Wall Qwest Information Technology, Inc. kevin.w...@qwest.comPhone: 614.215.4788 It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration - Edsger Dijkstra, How do we tell truths that matter? http://www.cs.utexas.edu/~EWD/transcriptions/EWD04xx/EWD498.html ___ 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] IBM Acquires Ounce Labs, Inc.
Arian J. Evans wrote... The problem I had in the past with benchmarks was the huge degree of customization in each application I would test. While patterns emerge that are almost always automatable to some degree, the technologies almost always require hand care-and-feeding to get them to an effective place. I think this notion of combining the tools with qualified users is the true potential power of the SaaS solutions that are coming to market. It's a pity that the these dynamic-scanning vendors can't work together to come up with a common approach to at least helping this automation you speak of at least part way along. (Yes, I know. I'm dreaming. ;-) Some ideas that I've had in the past is that they could request and make use of: 1) HTTP access logs from Apache and/or the web / application server. These might be especially useful when the logs are specially configured to also collect POST parameters and then the application's regression tests are run against the application to collect the log data. Most web / app servers support Apache HTTPD style access log format, so parsing shouldn't be too terribly difficult in terms of the # of variations they need to handle. 2) For Java, the web.xml could be used to gather data that might allow some automation, especially wrt discovery of dynamic URLs that otherwise difficult to discover by autoscanning. 3) If Struts or Strut2 is being used, gather info from the Struts validators (forget OTTOMH what the XML files called where this is placed, bot those are what I'm referring to). 4) Define some new custom format to allow the information they need to be independently gathered. Ideally this would be minimally some file format (maybe define a DTD or XSD for some XML format), but their tools could offer some GUI interface as well. Of course, I'm not sure I'd expect to see anything like this in my lifetime. At this point, most of the users of these tools don't even see this as a need to the same degree that Arian and readers of SC-L do and it's not clear how vendors addressing these shortcomings IN A COMMON WAY would help them to compete. More likely, we'll get there from here by evolution and vendors copying ideas from one another. The other significant driver AGAINST this as I see it as many vendors sell professional services for specialized consulting on how to do these things manually. That bring in extra $$ into their companies so convincing them to give up their cash cow is a hard sell. And as a purchaser of one of these tools, if you don't have the needed expertise in house (many do, but I'm guessing a lot more don't), it's hard to tell your director that you can't use that $75K piece of shelfware that your security group just bought because they can't figure out how to configure it. Instead, they are more likely to quietly just drop another $10K or so for consulting discretely and hope their director or VP doesn't notice. -kevin -- Kevin W. Wall 614.215.4788Application Security Team / Qwest IT The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents.-- Nathaniel Borenstein, co-creator of MIME ___ 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] Source or Binary
In a message dated July 30, 2009 10:09 AM EDT, Paco Hope wrote... The Java Virtual Machine is a theoretical machine, and Java code is compiled down to Java bytecode that runs on this theoretical machine. The Java VM is the actual Windows EXE that runs on the real hardware. It reads these bytecodes and executes them. There is a very significant level of abstraction between a Java program running in a Java virtual machine and native code that has been compiled to a native object format (e.g., an .exe). There's theory, and then there's practice. This is almost 100% accurate from a practical matter with the exception of HotSpot or other JIT compiler technologies that compile certain byte code into machine code and then execute that instead of the original byte code. I'm sure that Paco is aware of that, but just not sure all the other readers are. -kevin --- Kevin W. Wall Qwest Information Technology, Inc. kevin.w...@qwest.comPhone: 614.215.4788 It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration - Edsger Dijkstra, How do we tell truths that matter? http://www.cs.utexas.edu/~EWD/transcriptions/EWD04xx/EWD498.html ___ 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] implementable process level secure development thoughts
Andy, You wrote... I have been working on developing a series of documents to turn the ideas encompassed on this list and in what I can find in books articles. I am not finding, and it may just be I am looking in the wrong places, for any information on how people are actually implementing the concepts. I have found the high level ideas (like in Software Security and the MS SDL) and the low level code level rules, but there does not seem to be any information on how these two are being merged and used in actual development projects. Are there any non-proprietary materials out there? If there are none, could this be part of the problem of getting secure development/design/testing/coding out into the real world? Not sure what you are exactly looking for, but I recently reviewed the book Integrating Security and Software Engineering: Advances and Future Vision, Mouratidis H., Giorgini P., IGI Global, 2006, ISBN-10: 1599041480, ISBN-13: 978-1599041483. for Computing Reviews. (Review was posted online a 2 or 3 weeks ago. Not sure if it's still up or not.) The cost for the book on Amazon.com is ~$80. This book covered some of the gaps that you may be referring to. E.g., it covered quite a few secure design methodologies and how they (more or less) fit into an SDLC. NOTE: This book is very academic in nature and difficult reading and does not truly reflect current _practice_. However, it has a excellent bibliography that is useful if you wish to explore the topics more deeply. Can't really say much more about this (at least in a public forum) because Computing Reviews (http://www.reviews.com/) owns the copyright of the review. Contact me off-list if you want any specific question answered regarding this book. -kevin --- Kevin W. Wall Qwest Information Technology, Inc. [EMAIL PROTECTED] Phone: 614.215.4788 It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration - Edsger Dijkstra, How do we tell truths that matter? http://www.cs.utexas.edu/~EWD/transcriptions/EWD04xx/EWD498.html This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. ___ 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] Tools: Evaluation Criteria
James McGovern wrote... Maybe folks are still building square windows because we haven't realized how software fails and can describe it in terms of a pattern. The only pattern-oriented book I have ran across in my travels is the Core Security Patterns put out by the folks at Sun. Do you think we should stop talking solely about code and start talking about how vulnerabilities are repeatedly introduced and describe using patterns notation? You might want to check out securitypatterns.org, and more specifically, http://www.securitypatterns.org/patterns.html which mentions a few other books. I think there are a few other books by Markus Schumacher, one of which was based on his doctoral dissertation that is not shown there. As to your question, should we stop talking _SOLEY_ about code? Probably, yes. But I think the reason we don't is two-fold -- the first is that most of us view that as the easy-part, the low-hanging fruit so-to-speak. The second is that the development community for the most part, still doesn't seem to be applying the securing CODING principles, so many of us think it would be premature to move on to try to teach them secure design principles, developing security reqts with abuse cases, etc., threat modeling, etc. From a personal POV, I think that's something that a small team of security specialists can handle. (At least it mostly works here. Security evaluations are mandatory shortly after the design is complete.) But we can't possibly do manual code inspections with a small security team, so we try to instruct (alas, w/out too much success) developers secure coding practices to avoid the problems at that level in the first place. -kevin --- Kevin W. Wall Qwest Information Technology, Inc. [EMAIL PROTECTED] Phone: 614.215.4788 The reason you have people breaking into your software all over the place is because your software sucks... -- Former whitehouse cybersecurity advisor, Richard Clarke, at eWeek Security Summit This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. ___ 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] Economics of Software Vulnerabilities
James McGovern apparently wrote... The uprising from customers may already be starting. It is called open source. The real question is what is the duty of others on this forum to make sure that newly created software doesn't suffer from the same problems as the commercial closed source stuff... While I agree that the FOSS movement is an uprising, it: 1) it's being pushed by customers so much as IT developers 2) the uprising isn't so much as being an outcry against security as it is against not being able to have the desired features implemented in a manner desired. At least that's how I see it. With rare exceptions, in general, I do not find that the open source community is that much more security consciousness than those producing closed source. Certainly this seems true if measured in terms of vulnerabilities and we measure across the board (e.g., take a random sampling from SourceForge) and not just our favorite security-related applications. Where I _do_ see a remarkable difference is that the open source community seems to be in general much faster in getting security patches out once they are informed of a vulnerability. I suspect that this has to do as much with the lack of bureaucracy in open source projects as it does the fear of loss of reputation to their open source colleagues. However, this is just my gut feeling, so your gut feeling my differ. (But my 'gut' is probably bigger than yours, so feeling prevails. ;-) Does anyone have any hard evidence to back up this intuition. I thought that Ross Anderson had done some research along those lines. -kevin --- Kevin W. Wall Qwest Information Technology, Inc. [EMAIL PROTECTED] Phone: 614.215.4788 It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration - Edsger Dijkstra, How do we tell truths that matter? http://www.cs.utexas.edu/~EWD/transcriptions/EWD04xx/EWD498.html This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. ___ 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] Vulnerability tallies surged in 2006 | The Register
Benjamin Tomhave wrote... This is completely unsurprising. Apparently nobody told the agile dev community that they still need to follow all the secure coding practices preached at the traditional dev folks for eons. XSS, redirects, and SQL injection attacks are not revolutionary, are not all that interesting, and are so common-place that it makes one wonder where these developers have been the last 5-10 years. Solution to date: throw out traditional design review, move to agile security testing. Why? Because there seems rarely to be a design to review, and certainly no time to do it in. Overall, it's important that agile apps be built on an underlying publishing framework so that inherited vulns can be found and fixed across the board by focusing on a single platform. I think many in the security community have had similar thoughts for years. IIRC, I think Gary McGraw even made a prediction at one point that agile development methods would be the worst setback to information security in years, or something to that affect. (At least I think it was Gary. If not, my bad memory is at fault. Or perhaps I should say... my bad...memory?) Agile development is good at things when their users have some idea of how they'd like to see the system work, so it usually works fairly well for things like laying out screens, workflow, etc. as well as many business applications which are presently being done manually. However, generally these users are clueless when it comes to security. If the developers were using a more traditional SDLC and their users were writing up business requirements, the typical requirement (ones I have actually seen) are things like The user must login and The system must be secure. That's about as sophisticated as they get. If your have developers are know a lot of security, then they _might_ make it work, but the agile development methods, which emphasizing working closely with your users, doesn't work well for security matters because most users don't even know what to ask for. IMO, another reason why agile development fails miserably to result in secure programs is because security cuts across the grain of the entire application. While you can have a trusted kernel or whatever be a logically isolated component, much of security has to be DESIGNED IN, FROM THE START. Because all it takes is a single incorrectly functioning piece to ruin your entire security. Most agile development teams that I've seen here think that they can leave security issues to the end that then put in in that special security module. One problem is that security must be anywhere that untrusted input can come from which is usually quite a few places. In that sense, trying to add in security to an application developed using agile methods is similar to attempting to add concurrency / multi-threading to an application after-the-fact. Sure, you _can_ do it, but what it results in is a system with a few course grained locks and very little concurrency. Concurrency cuts across various aspects, just like security does. That's why I don't see it as a particularly good fit for agile development. (OTOH, I think it should be a great fit with Aspect Oriented Programming, but that's another topic.) And while I'm on a roll (at least in the ego of my own mind ;-) one other place that I think is a rotten match for agile development. If the software you are developing is supposed to be a reusable class library, I don't find agile development a particularly good fit. Publish the interfaces of a reusable class library for the first release and then go ahead and just try to refactor those interfaces after you have a 1/2 dozen clients using release 1.0. If they don't skin you alive, they certainly won't be your clients for your next release. But enough rambling. -kevin --- Kevin W. Wall Qwest Information Technology, Inc. [EMAIL PROTECTED] Phone: 614.215.4788 The reason you have people breaking into your software all over the place is because your software sucks... -- Former whitehouse cybersecurity advisor, Richard Clarke, at eWeek Security Summit This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. ___ 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]
Crispin Cowan wrote... mikeiscool wrote: ... True, but that doesn't mean runtime portability isn't a good thing to aim for. It means that compromising performance to obtain runtime portability that does not actually exist is a poor bargain. To me, the bigger loss than performance is all the functionality that you give up to gain the portability. E.g., because several system calls (in a functional/feature way, not the _specific_ sys calls) aren't portable across all OSes that Sun wanted to support with Java, they dumbed down the list to the lowest common demoninator. That makes a Java inappropriate for a lot of system-level programming tasks. 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. Plea to moderator: Ken: While I find this debate interesting, I think it has little to do with secure coding. I'm trying to bring it back on track a bit, but I fear that it is too far gone. My vote is to kill this topic unless someone has a major objection or we can make it relevant to security. Thanks. -kevin --- Kevin W. Wall Qwest Information Technology, Inc. [EMAIL PROTECTED] Phone: 614.215.4788 It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration - Edsger Dijkstra, How do we tell truths that matter? http://www.cs.utexas.edu/~EWD/transcriptions/EWD04xx/EWD498.html This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. ___ 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-writing college books - erm.. ahm...
In response to a post by Jerry Leichter, Gadi Evron wrote... A bridge is a single-purpose device. A watch is a simple purpose computer, as was the Enigma machine, if we can call it such. Multi-purpose computers or programmable computers are where our problems start. Anyone can DO and create. One simply has to sit in front of a keyboard and screen and make it happen. Let us keep in mind that in the name of profits (and ignoring our prophets, see .sig, below), as an industry, we have strived to lower the entry level of programming by introducing diseases (I'll probably catch some flack for that) such as Visual Basic, etc. so that managers who have never had even the simplest introduction to computer science can now develop their own software, complete with security vulnerabilities. This only exacerbates the situation. To add to that, often you get some manager or marketing type who slaps together a working prototype of something they or a customer is asking for by using a spreadsheet, an Access database, and some VB glue that works for maybe 100 records and then s/he thinks that a small development team should be able to tweak that prototype to turn it into an enterprise-wide, Internet-facing application that can handle millions of records, handle a transaction volume that is 3 or 4 orders of magnitude larger than the prototype handles, and slap it all together in a couple of weeks. Developers have to cut corners somewhere, and since security issues are not paramount, that's often what gets overlooked. As an industry, I think that we've, in part, done this to ourselves. When I started in this industry 27 years ago, at least real software engineering techniques were _attempted_. There were requirements gathered, specifications written and reviewed, designs written, reviewed, and applied, and an extensive testing period after coding was more or less complete. But that used to take 15-20 people about 1 to 2 years. Now we've compressed that down to 90 days or so, so something had to give (besides our sanity ;-). What I see today is a few analysts go talk to marketing or other stakeholders and they write up some user stories (not even real use cases; what I'm referring to but more like a sentence or two describing some basic, sunny-day-only usage scenario collected into a spreadsheet). From there, the application development teams jump directly into coding/testing, magically expecting the design to somehow just emerge or expecting to be able to refactor it later (if there ever is a later). (Can you tell I think that extreme programming--at least as practiced here--has been a horrible failure, especially from a security POV? :) I ask you, just where would civil or mechanical engineering be today if they had encouraged the average construction worker to develop their own bridge or designed their own buildings rather than relying on architects and engineers to do this? That's just one reason why things are as bad as they are. Today, I don't even see professional software developers develop software using good software engineering principles. (It takes too long or It's too expensive are the usual comments.) Or where would we be if the city council expected to build a new 80-story skyscraper, starting from inception, in only 6 months? It's no wonder that we so often here that remark that says If [building] architects built buildings the way that software developers build software, the first woodpecker that came by would destroy civilization. Maybe what we need is to require that as part of the software development education, we need to partly indoctrinate them into other real engineering disciplines and hope that some of it rubs off. Because, IMO what we are doing now is failing miserably. BTW, if you've not yet read the Dijkstra article referenced below, I highly recommend it. It's quite dated, but it's a gem for .sig quotes. -kevin Std disclaimer: Everything I've written above reflects solely my own opinion and not the opinion of any of my employers, past or present. --- Kevin W. Wall Qwest Information Technology, Inc. [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Phone: 614.215.4788 It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration - Edsger Dijkstra, How do we tell truths that matter? http://www.cs.utexas.edu/~EWD/transcriptions/EWD04xx/EWD498.html http://www.cs.utexas.edu/~EWD/transcriptions/EWD04xx/EWD498.html This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.
Re: [SC-L] How can we stop the spreading insecure coding examplesattraining classes, etc.?
Tim Hollebeek writes... Really, the root of the problem is the fact that the simple version is short and easy to understand, and the secure version is five times longer and completely unreadable. While there always is some additional complexity inherent in a secure version, it is nowhere near as bad as current toolkits make it seem. I would say that secure versions that are *not* well thought out (particularly where security wasn't part of the original design) may tend to be FIVE times longer, but I don't think that's the typical case with code that is well designed. These security checks can be be modularized and reused like most other code. However, it may very well be that it is five times more difficult to develop the examples in the first place though, and THAT'S probably a major reason that we don't see it more often in example code. Demo code generally demonstrates some fairly powerful capability; the reason it is often short and sweet is because lots of effort has gone into making it possible to do useful things with minimal effort. Unfortunately, it is often the case that much less effort has gone into making it possible to do the same thing securely, so that code is quite a bit longer. You're right, if there was more of a pushback against broken demo code, maybe more effort would go into making it easy to do things securely, instead of insecurely. Well, I'm going to start pushing back when I can. Tomorrow I get the chance to bend the ear of some security folks from the Live.com site. I'm definitely going to be letting them know of my dissatisfaction wrt recent MS Atlas training and asking what I can do about it (other than completing the training evaluation). Every little bit helps. As Ed Reed pointed out, as an industry we did manage to get rid of computed gotos, spaghetti code, etc., so maybe there's hope. (But the pessimist in me says that it's probably easier to get people to _stop_ doing some poor practice than to start doing some good practice. I hope I'm wrong there.)-: For the moment, perhaps all we can do is try to publically shame them and bring about peer presure that way. I dunno. I think it's primarilly a people problem rather than simply a technological one, which is why it's so hard to solve. So while doing things like showing people secure coding idioms and secure design patterns (ala Marcus Schumacher) will only have minor impact until there is some major attitude change with both developers and upper management. I think part of the problem is that people have fallen into the trap of thinking that security is supposed to be hard and that checking all your errors is supposed to bloat your code by a factor of five, instead of wondering why library functions are designed in such a way that omitting complex logic around them fails in an insecure way. Secure code can be short and sweet, too, just not with most of the languages and tools that are currently popular. That's definitely a large part of it. Historically, most libraries haven't taken much of a security slant unless they've been crypto related. Most often, they first become well entrenched, and *then* there's an outpour of security vulnerabilites discovered as the library usage builds up a critical mass of usage. E.g., libc was this way. It wasn't until the Morris Internet worm in 1988 that people really started paying much attention to libc security issues. By that time libc was pretty much everywhere and what's worse, there wasn't really any viable alternative unless you wanted to roll your own. (That was long before GNU was prevalent.) And yes, buffer overflows were known very early, before Unix/C were widespread. But it was a different world then. This is an old, old problem. strcpy is insecure, and any code involving strncpy or a length check will be longer and/or more complex. But this is really just an artifact of the fact that buffers don't know their own length, making an additional check necessary. There is no reason why the secure version couldn't have been just as short and sweet, it just wasn't done. Or when strcpy() and its ilk were originally written, no one was concerned about buffer overflows...they were more concerned with program speed and size. The world changes. IMO, if you are still writing in a unsafe language like C or C++ when you don't really have to and are only using it because that's ALL YOU KNOW, then someone should take away your keyboard. Obviously there are legitimate reasons for using C/C++ and other pointy languages, but those reasons are holding less and less water every day. In the security class I've taught for the past 4.5 yrs or so, one of the things I tell my students is, if you have a choice, select a 'safe' language like Java or C# where you don't need to worry about buffer overflows or heap corruption. Not only is it safer, but it is also likely to improve your productivity. But at this point, I'd be (somewhat) okay with those showing
[SC-L] How can we stop the spreading insecure coding examples at training classes, etc.?
First a bit of background and a confession. The background: I recently attended a local 4 hr Microsoft training seminar called Get Connected with the .NET Framework 2.0 and Visual Studio(c) 2005. However, I want to clarify that this example is NOT just a Microsoft issue. It's an industry-wide issue; only the examples I give are from this most recent Microsoft training seminar. (Actually, calling it training is probably a stretch; it was more like and advertisement for .NET Framework 3.0 (a.k.a., Atlas) and a forthcoming version of Visual Studio, but that's another gripe. ;-) The confession: 90% of the examples presented at this training was in Visual Basic and about 10% was C#. I personally think that VB is horrid as a programming language (for the most part, I concur with Dijkstra about anything BASIC-like; see .sig, below), and so may be causing some bias with my observations. Anyway, back to the main point. At this training seminar, the demo code that they showed (which mostly was about Atlas features, not about .NET Framework 2.0 features) had very little in the way of proper security checks. This was most notable in the almost complete absence of authorization checks and proper data validation checks. Also, most of these quotations below are actually paraphrases (including my own!), but nevertheless, I believe they are fairly accurate and hopefully non-biased. At one point, the speaker asked what's wrong with this code fragment (a demo to upload a file). I said there's no proper data validation, so one can use a series of '..\' in the file name and use it to do directory traversal attacks and overwrite whatever file the user id running the web server has permissions to write to. (Of course, that was the wrong answer. Their proper answer was that W3C had instituted a max size of 4MB or so on files that could be uploaded in this manner, but they had a mechanism to get around it.) At another point, while Atlas JavaScript gadgets was being demoed, someone asked if one could use XMLHttpRequest (XHR) to invoke _any_ URL. The speaker correctly answered no; only back to the originating host:port from where the JavaScript was downloaded from. The questioner then remarked something like oh, that's too bad. But instead of explaining why allowing cross-domain requests is inherently a BAD Thing, the speaker replied oh, don't worry; we also provide you with some software [apparently a proxy of sorts -kww] that Microsoft wrote that you can put on your web server so your users can call out to any URL that they wish, so it's not limited to calling just pages on your own site. Great, I thought. Why don't you also provide some mechanisms to automatically insert random XSS and SQL injection vulnerabilities into your code too. Sigh. Now understand, these are only a few recent examples presented at this training. Over the past few years, I've seen numerous other lame examples of demo code elsewhere, ranging from symmetric encryption examples using block ciphers (where it's implied that you should always just use ECB mode; in fact no other cipher modes are even mentioned!), to showing how to create a web service without even mentioning any mechanisms for authentication or authorization. (Actually, many typically don't even _recognize_ the NEED for such things.) Make no mistake in thinking that this poor practice is limited to Microsoft. At one point or another, we probably have all done something like this and then just casually mentioned of course you need to do X, Y, and Z to make it secure. I understand the the pedagogical need that example code has to be kept simple. Usually much of the error code is completely omitted, not just security-related checks. But most developers have enough sense of the application-related errors to know they need to add the application-level error checking; not so for security-related checks--at least not for your average developer. Of course the big problem with any poor examples is that this is just the type of thing that developers who have little security experience will copy-and-paste into their PRODUCTION code, thus exposing the vulnerabilities. And nowadays, it's even made easier to copy-and-paste this insecure code by either making it available for download from the Internet or passing it out on a CD or DVD. Many of us have probably been guilty of that too, at least once in our lives. But we need to all recognize that there is no reason that the demo code that made available for downloading or on a CD needs to be the exact same code displayed during the training. (N.B.: I've not yet checked the DVD supplied by Microsoft, but the instructors said [paraphrase] we would find the exact same code were are using in our examples on the DVD.) I think that this practice of leaving out the security details to just make the demo code short and sweet has got to stop. Or minimally, we have to make the code that people copy-and-paste from have all the proper security checks even if we
Re: [SC-L] bumper sticker slogan for secure software
Dana, Regarding your remarks about writing perfectly secure code... well put. And your remarks about Ross Anderson... Ross Anderson once said that secure software engineering is about building systems to remain dependable in the face of malice, error, or mischance. I think he has something there. If we build systems to maintain confidentiality, integrity and availability, we have the ability to fail gracefully in a manner to recover from unknown or changing problems in our software without being detrimental to the user, or their data. remined me of Anderson and Ralph Needham coining the phrase (hope I'm getting this right) that security is like programming Satan's computer in the sense that you have an evil extremely intelligent adversary with unlimited resources and time, etc. [http://www.cl.cam.ac.uk/ftp/users/rja14/satan.pdf] So there's a bumper sticker for you: Security: programming Satan's computer Of course, it's likely to be misunderstood by most. (Maybe we could attribute it to SNL's church lady. Sorry Ross. ;-) BTW, does anyone besides me think that it's time to put this thread to rest? -kevin --- Kevin W. Wall Qwest Information Technology, Inc. [EMAIL PROTECTED] Phone: 614.215.4788 The reason you have people breaking into your software all over the place is because your software sucks... -- Former whitehouse cybersecurity advisor, Richard Clarke, at eWeek Security Summit This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. ___ 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] By default, the Verifier is disabled on .Net and Java
David Eisner wrote... Wall, Kevin wrote: The correct attribution for bring this up (and the one whom you are quoting) is Dinis Cruz. same intuition about the verifier, but have just tested this and it is not the case. It seems that the -noverify is the default setting! If you want to verify classes loaded from the local filesystem, then you need to explicitly add -verify to the cmd line. Is this (still) true? The -verify and -noverify flag are no longer documented [1], although they are still accepted. I did a little experiment (with my default 1.5 VM). I compiled a HelloWorld program, then changed a few byes in the class file with a hex editor. Perhaps no longer true (at least one could hope), but I can't take credit for the part you quoted above. That was Dinis. Also, from the results of your test, it seems to indicate that SOME TYPE of verification is taking place, but if all you did was change a few ARBITRARY bytes in the .class file, I don't think that proves the byte code verifier is being being run in it's entirety. IIRC, the discussion was around the issue of 'type safety'. It's hard to see how a HelloWorld program would show that. It's entirely possibly that the (new 1.5) default just does some surface level of byte code verification (e.g., verify that everything is legal op codes / byte code) before HotSpot starts crunching on it and that this works differently if either the '-verify' or '-noverify' flags are used. E.g., suppose that '-verify' flag, does some deeper-level analysis, such as checks to ensure type safety, etc, whereas the '-noverify' doesn't even validate the byte codes are legal op codes or that the .class file has a legal format. This might even make sense because checking for valid file format and valid Java op codes ought to be fairly cheap checks compared to the deeper analysis required for things like type safety. You didn't discuss details of what bits you tweaked, so I'm not quite yet ready to jump up and down for joy and conclude that Sun has now seen the light and has made the 1.5 JVM default to run the byte code through the *complete* byte code verifier. I think more tests are either necessary or someone at Sun who can speak in some official capacity steps up and gives a definitive word one way or another on this. -kevin --- Kevin W. Wall Qwest Information Technology, Inc. [EMAIL PROTECTED] Phone: 614.215.4788 Linux *is* user-friendly. It's just choosy about its friends. - Robert Slade, http://sun.soci.niu.edu/~rslade/bkl3h4h4.rvw This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. ___ 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, Uservs Admin risk profile, and browsers coded in 100% Managed Verifiable code
Dinis, Dinis Cruz wrote... Finally, you might have noticed that whenever I talked about 'managed code', I mentioned 'managed and verifiable code', the reason for this distinction, is that I discovered recently that .Net code executed under Full Trust can not be (or should not be) called 'managed code', since the .Net Framework will not verify that code (because it is executed under Full Trust). This means that I can write MSIL code which breaks type safety and execute it without errors in a Full Trust .Net environment. Indeed this is somewhat surprising that there is no byte-code verification in place, especially for strong typing, since when you think about it, this is not too different than the unmanaged code case. Apparently the whole managed versus unmanaged code only has to do with whether or not garbage collection is attempted. Given the fact that Microsoft has added almost 50 new keywords just for their new managed C++, one certainly could hope they could do better than this--IF this applies to ALL managed code in general. However, the real question is is this true for ALL managed code or only managed code in the .NET Framework? If it is the latter, I don't see it as being much different where Java java.* packages may use native code (via JNI) in (say) rt.jar to interface with OS-level constructs. I believe that such code is fully-trusted in the JVM as well. Of course, it is reasonable to ask of Sun Microsystems and Microsoft to restrict such trust for native and managed code (respectively) by requiring it be limited to digitally signed jars / assemblies signed by trusted sources that are verified at runtime when these jars / assemblies are first loaded. This could be extended so that the trusted sources ultimately could be defined by the end users (or their administrators), but by default, it would include the vendors (Sun and Microsoft) themselves. I recall early versions of Sun's domestic JCE jars that were distributed as separate jars. The verification of the signatures for these signed jars significantly slowed down the initial loading of those jars, but after verification, it had little, if any performance impact. Of course if software quality improvement does not take place in these companies, their signing would be somewhat vacuous. But it would be better than nothing, since at least all such code would not be fully trusted by default. Of course (not to open another can of worms) if we could actually enforce liability for software just as we commonly do with other manufactured products, we problably wouldn't need some elaborate constructs to ensure secure coding. Because once some of the major vendors had had their feet held to the fire and been burned by millions or billions in lawsuits, I suspect all of a sudden they would SEE a valid business reason where none existed before. (Usual company disclaimers apply.) Comments? --- Kevin W. Wall Qwest Information Technology, Inc. [EMAIL PROTECTED] Phone: 614.215.4788 The reason you have people breaking into your software all over the place is because your software sucks... -- Former whitehouse cybersecurity advisor, Richard Clarke, at eWeek Security Summit ___ 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] Design flaw in Lexar JumpDrive
Joel Kamentz wrote... Also, shouldn't it be easy enough to steal one of these and lift a fingerprint from it with scotch tape and then be able to get at all of the passwords in the device? If that didn't work, the gummy bear approach probably would. --- Kevin W. Wall Qwest Information Technology, Inc. [EMAIL PROTECTED] Phone: 614.215.4788 The reason you have people breaking into your software all over the place is because your software sucks... -- Former whitehouse cybersecurity advisor, Richard Clarke, at eWeek Security Summit
RE: [SC-L] Top security papers
Matt Setzer wrote... It's been kind of quiet around here lately - hopefully just because everyone is off enjoying a well deserved summer (or winter, for those of you in the opposite hemisphere) break. In an effort to stir things up a bit, I thought I'd try to get some opinions about good foundational materials for security professionals. (I'm relatively new to the field, and would like to broaden my background knowledge.) Specifically, what are the top five or ten security papers that you'd recommend to anyone wanting to learn more about security? What are the papers that you keep printed copies of and reread every few years just to get a new perspective on them? Okay, for starters, in no particular order: Ken Thompson's Turing Award lecture, _Reflections on Trusting Trust_, URL: http://www.acm.org/classics/sep95/ Saltzer Schroeder, The Protection of Information in Computer Systems, Proceedings of the IEEE, Sept. 1975, pp. 1278-1308, available at: http://web.mit.edu/Saltzer/www/publications/protection/ David Wheeler, Secure Programming for Linux and Unix HOWTO, URL: http://www.dwheeler.com/secure-programs/ Aleph One, Smashing the Stack for Fun and Profit, URL: http://www.insecure.org/stf/smashstack.txt Bruce Schneier, Why Cryptography Is Harder Than It Looks, URL: http://www.schneier.com/essay-037.html Carl Ellison and Bruce Schneier, Ten Risks of PKI: What You're Not Being Told About Public Key Infrastructure, URL: http://www.schneier.com/paper-pki.html Also, I'd probably through in a few RFCs and the Firewall and Snake-Oil Cryptography FAQs in there as well, but I'm too lazy to look them up right now. -kevin --- Kevin W. Wall Qwest Information Technology, Inc. [EMAIL PROTECTED] Phone: 614.215.4788 The reason you have people breaking into your software all over the place is because your software sucks... -- Former whitehouse cybersecurity advisor, Richard Clarke, at eWeek Security Summit
RE: [SC-L] Programming languages used for security
David Crocker wrote... I think there are two other questions that should be asked before trying to answer this: 1. Is it appropriate to look for a single general purpose programming language? Consider the following application areas: a) Application packages b) Operating systems, device drivers, network protocol stacks etc. c) Real-time embedded software The features you need for these applications are not the same. For example, garbage collection is very helpful for (a) but is not acceptable in (b) and (c). For (b) you may need to use some low-level tricks which you will not need for (a) and probably not for (c). I did not mean to imply that a *SINGLE* general purpose programming language be the optimal, end-all, be-all solution for all software problems. Rather, I was trying to understand what would we, as security professionals, find useful in a programming language in terms of specific feature sets, etc. (At this point, I don't even want to particularly discuss syntax and semantics, although I would argue that these things do have an impact on secure coding as well.) The very reason that I stated a GENERAL PURPOSE programming language rather than just a programming language is I didn't want the discussion to digress into fine grained application areas such as for web applications, you need features F1 and F2, but for programming firewalls, you want features F1' and F2', etc. For any given application area, I'm of the opinion that you can design an application specific prog language that will be better suited and likely offer more security than you can in the general case. However, this is usually just not practical, which is why we have other mechanisms to extend the basic functionality of programming languages (usually application specific libraries). (Of course, sometimes the language itself goes beyond that; for example Prolog offers its Declarative Clause Grammar form which is great for parsing. And Forth can be used or abused almost ad infinitum.) My vary reason for posing these questions is to see if there is any type of consensus at all on what mechanisms / features a language should and should not support WITH RESPECT TO SECURE PROGRAMMING. For example, you mentioned garbage collection. To that I would add things like strong static typing, encapsulation that can not be violated, very restrictive automatic type conversion (if allowed at all), closed packages or libraries or some other programming unit, elegant syntax and semanatics (oops, said I wouldn't go there ;-), etc. In the past few days (actually, all through my career), I've hear a lot of gripes about what people think is wrong regarding languages, but little in terms of what they think is valuable. 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? [This is not yet feasible for operating systems, but it is feasible for many applications, including many classes of embedded applications]. Well, I guess I'd argue that this is _somewhat_ irrelevant. If you are proposing something like Z or VDM, than that in essence becomes your programming language for all practical purposes. How it's translated to machine code is not what I was trying to get at. IMO, I think that formal programming languages have their place, but given that 95% of programmers are weak in formal proofs, they are likely to be at least as error prone as more conventional programming languages for all but a select few. So, if you wish, you can rephrase my original question from general purpose programming language to general purpose high-level specification method. In either case, what would you like to see to specifically support writing secure software? (Obviously, the details will vary at spec methods vs. traditional prog languages as you are working at different levels, but I think my questions could be generalized / extended to deal with specifiction languages as well. -kevin wall David Crocker, Escher Technologies Ltd. Consultancy, contracting and tools for dependable software development www.eschertech.com Kevin Wall wrote: If a GENERAL PURPOSE programming language were designed by scratch by someone who was both a security expert and programming language expert, what would this language (and it's environment) look like? More specifically, + What set of features MUST such a language support (e.g., strong static typing, etc.)? + Perhaps just as importantly, what set of features should the language omit (e.g., pointer arithmetic, etc.)? + What functionality should the accompanying libraries support (e.g., encryption, access control, etc.)? + What would be the optimal paradigm (from a theoretical, rather than pragmatic perspective) that such a language would fit into (e.g., object-oriented,
RE: [SC-L] Programming languages used for security
David Crocker wrote: 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. [snip] In a specification language, you tell the computer what you are trying to achieve, not how to achieve it. This is typically done by expressing the desired relationship between the input state and the output state. The state itself is normally modelled at a higher level of abstraction than in programming (e.g. you wouldn't refer to a hash table, because that is implementation detail; you would refer to a set or mapping instead). I'm sorry, but I don't quite see how this description sufficiently delineates between declarative programming languages (such as SQL, various logic and functional prog langs (Prolog, ML, Haskell, Miranda, etc.)) from specification languages. Do you consider them declarative programming languages and specification languages one in the same? (Note: PLEASE, let's not turn this into a discussion of language X is / is not a declarative programming language, especially since the last time I used Prolog was in 1989 and the others I've only read about and/or wrote a few toy programs. ;-) My impression always has always been that a declarative programming language is a high-level language that describes a problem rather than defining a solution, but that pretty much sounds like your definition of a specification language. -kevin wall --- Kevin W. Wall Qwest Information Technology, Inc. [EMAIL PROTECTED] Phone: 614.215.4788 The reason you have people breaking into your software all over the place is because your software sucks... -- Former whitehouse cybersecurity advisor, Richard Clarke, at eWeek Security Summit
[SC-L] Programming languages used for security
I think the discussion regarding the thread Re: [SC-L] Education and security -- another perspective (was ACMQueue - Content) is in part becoming a debate of language X vs language Y. Instead, I'd like to take this thread off into another direction (if Ken thinks it's appropriate to the charter of this list). [Perhaps, this has been discussed before here or elsewhere. A quick Google search revealed a thread in SecurityFocus 'Security Basics' mailing list that didn't contain much in the way of substance.] [Ed. Concur, and I was rapidly approaching the point of asking the thread to die or go elsewhere. The pros and cons of a particular language's strength in an academic curriculum are interesting, however -- particularly when it comes to issues re teaching students secure coding practices. KRvW] Anyway, here's my question... If a GENERAL PURPOSE programming language were designed by scratch by someone who was both a security expert and programming language expert, what would this language (and it's environment) look like? More specifically, + What set of features MUST such a language support (e.g., strong static typing, etc.)? + Perhaps just as importantly, what set of features should the language omit (e.g., pointer arithmetic, etc.)? + What functionality should the accompanying libraries support (e.g., encryption, access control, etc.)? + What would be the optimal paradigm (from a theoretical, rather than pragmatic perspective) that such a language would fit into (e.g., object-oriented, functional, imperative, logic programming, etc.)? [Note: I mention theoretical, rather than pragmatic so that such a language would be unduly influenced by the fact that presently developers familiar with OO and imperative styles vastly out number all the others, with functional coming up a distant 3rd.] + (Related to the previous item) Would such a language be compiled or interpreted or something in between. Also, if anyone chooses to discuss these issues, let's leave things like portability and performance out of the equation UNLESS you feel these things directly have an impact on secure coding. I think that we can all agree that we'd desire a portable and fast-executing language (although perhaps a slow-executing language would be more secure in that it might slow down the propagation of malware ;-). Finally, lets try to keep this abstract and not a grocery list of it should have X, Y, and Z, which by the way happens to be in name_of_your_pet_language_here. Looking for the ensuing discussion (assuming Ken thinks this is appropriate to this lists charter). -kevin --- Kevin W. Wall Qwest Information Technology, Inc. [EMAIL PROTECTED] Phone: 614.215.4788 The reason you have people breaking into your software all over the place is because your software sucks... -- Former whitehouse cybersecurity advisor, Richard Clarke, at eWeek Security Summit
RE: [SC-L] Education and security -- another perspective (was ACM Queue - Content)
David Crocker wrote... There is a tendency to regard every programming problem as an O-O problem. Sometime last year I read a thread on some programming newsgroup in which contributors argued about the correct way to write a truly O-O Hello world program. All the solutions provided were cumbersome compared to the traditional printf(Hello, world!) solution. The point is, printing Hello, world! is not an O-O problem! Amen to that! I made similar remarks in the 'comp.compiler' and 'comp.object' USENET newsgroups as far back as 1991 (see for example [URL probably will wrap] ... http://groups.google.com/groups?hl=enlr=lang_enie=UTF-8newwindow=1safe=activethreadm=91-08-148%40comp.compilersrnum=1prev=/groups%3Fq%3Dcblph!kww%2Bgroup:comp.*%26hl%3Den%26lr%3Dlang_en%26ie%3DUTF-8%26newwindow%3D1%26safe%3Dactive%26selm%3D91-08-148%2540comp.compilers%26rnum%3D1) I also muttered similar things within the Bell Labs community much earlier than that during a time that C++ was first gaining momentum. I'm of the belief that one should use the appropriate programming paradigm that best fits the problem at hand. Contrary to how some may feel, I strongly believe that does NOT mean that the best solution is always an OO approach. Unfortunately, when all you have is a hammer... [Note: In general, I'm a fan of OO--where and when appropriate.] But this is getting way-off topic, so I'll cease my ranting. (About time he shuts up! ;-) -kevin --- Kevin W. Wall Qwest Information Technology, Inc. [EMAIL PROTECTED] Phone: 614.215.4788 The reason you have people breaking into your software all over the place is because your software sucks... -- Former whitehouse cybersecurity advisor, Richard Clarke, at eWeek Security Summit
RE: [SC-L] Education and security -- another perspective (was ACM Queue - Content)
Fernando Schapachnik wrote... I've considered 'secure coding' courses, and the idea always look kind oversized. How much can you teach that students can't read themselves from a book? Can you fill a semester with that? I'm interested in people's experiences here. I suppose that depends largely on how you define secure coding and how much depth you want to go into. For the past 2 years I've taught a CS masters level course in computer security. In addition to secure coding practices, I also discuss: * fundamental concepts of security (e.g., authentication, authorization, confidentiality, data integrity, nonrepudiation, etc.); * risk management and threat models; * cryptographic foundations; * authentication, access control, and auditing; * common threats and vulnerabilities, and * designing secure systems. For the most part, because of time constraints and the fact that we are trying to cover broader things then simply coding-related issues, the secure coding practices are interspersed with the other topics, where and when appropriate. (If you want more detail, you can find the syllabus at http://cs.franklin.edu/Syllabus/comp676/.) Adding a 'security chapter' to existing courses seems more appropiate (at least to me). At the end of our Programming II course, I showcase students the vulnerabilities that can be understood or are related with what they've saw in class: these includes buffer overflows, input validation, integer over/underflows, race conditions, least priviledge, etc. I stress that these are only samples, and point them to links (like David's great 'Secure Programming How-To') and books. I haven't had the chance to evaluate the impact of that, but it is on my to-do list. I think that is a good approach, although I prefer mixing these issues in where/when they might be more appropriate (e.g., discuss security issues arising from race conditions when discussing multi-threading, etc.) rather then saving them up for the end--if only because there's a chance that they get crowded out if the pace goes slower than expected. Similary, some other courses where security can be plugged include operating systems, networking, SE, system's design, etc. Indeed. At the same university, I taught the Distributed Operating Systems masters level course. We used the Tannebaum / van Steen text. The longest single chapter in the book was on security, so the topic naturally fit in. (However, I know of other instructors before me who simply skipped that chapter, thinking it wasn't as important as the rest of the stuff.) I'd be interested to hear what people think of the two approaches (separate security courses vs. spreading security all over the curricula). I don't see it as either / or, but rather both / and. I think that we sprinkle discussion of security, where appropriate, throughout core courses (OS, networking, software design, etc.) and also have a course or two at an upper (junior/senior) level. In that way, I see it very similar to the way that we approach software design. Generally there's a specific course or two on design, but we (hopefully) teach it in bits and pieces at the beginning programming levels as well. --- Kevin W. Wall Qwest Information Technology, Inc. [EMAIL PROTECTED] Phone: 614.215.4788 The difference between common-sense and paranoia is that common-sense is thinking everyone is out to get you. That's normal -- they are. Paranoia is thinking that they're conspiring.-- J. Kegler
RE: [SC-L] Protecting users from their own actions
In Ken van Wyk's cited article at http://www.esecurityplanet.com/views/article.php/3377201 he writes... As I said above, user awareness training is a fine practice that shouldn't be abandoned. Users are our first defense against security problems, and they should certainly be educated on how to spot security problems and who to report them to. By all means, teach your users to be wary of incoming email attachments. Teach them to keep their anti-virus software up to date, and their firewall software locked down tight. Do not, however, be shocked when they make the ''wrong'' choice. I would contend that in any sufficiently large user population the probability that someone will open up a suspect attachment approaches one. In fact, I think that in a sufficiently large population, this probability approaches 1 even if: 1) the e-mail were from a complete stranger; 2) the name of attached file was i_am_a_worm_that_will_destroy_your_harddrive.exe. (#2 assuming that your mail filter didn't catch something so obvious -- and it it didn't, time to revise your filtering rules! ;-) So, I completely agree that we ought to EXPECT that users will do foolish things (with malice or out of ignorance--I'm not trying to make a moral judgement here) and thus we need to be prepared to practice security in depth. However, (repeating here, from above) Ken also wrote... ... Teach them [users] to keep their anti-virus software up to date, and their firewall software locked down tight. I'm not sure why this is something that should be left up to users. Isn't this something that users probably shouldn't be given a choice on? Normally I would think that corporate security policy dictate keeping the AV software / signatures up-to-date as well as dictating the (personal) firewall configurations. Some centrally administered software should do these things. I don't think that (except under very rare circumstances), users should even be given a _choice_ about such things. While that may seem Draconian to some, thats what works best in practice. Cheers, -kevin --- Kevin W. Wall Qwest Information Technology, Inc. [EMAIL PROTECTED] Phone: 614.215.4788 The difference between common-sense and paranoia is that common-sense is thinking everyone is out to get you. That's normal -- they are. Paranoia is thinking that they're conspiring.-- J. Kegler
[SC-L] Education and security -- another perspective (was ACM Queue - Content)
Kenneth R. van Wyk wrote... FYI, there's an ACM Queue issue out that focuses on security -- see http://acmqueue.com/modules.php?name=Contentpa=list_pages_issuesissue_id=14 Two articles there that should be of interest to SC-L readers include Marcus Ranum's Security: The root of the problem -- Why is it we can't seem to produce secure, high quality code? ...snip... I've been thinking alot about some of the statements that Marcus Ranum made in his most recent article in the _ACM Queue_ (Vol 2, No 4)... even before Ken invited us all to comment on it. I mostly agree with Ranum's conclusions, although perhaps for different reasons. Ranum states: It's clear to me that we're: + Trying to teach programmers how to write more secure code + Failing miserably at the task He goes on to say that it [educational approach] flat out hasn't worked. 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. For the past 25 years, I've worked closely with both highly educated Ph.D. computer scientists and with those whose formal CS education consisted of at most a course or two in something like C or Pascal. In many of these cases, the less educated are beating out those who have had more formal education. (In fact, I'd say this has been true in at least as many as 50% of the cases.) What makes the difference? Well, it goes beyond mere aptitude and general intelligence. I think in part at least, it goes with having a passion for what you do. To some, doing design and coding and other creative aspects is an artistic expression, a noble cause and they would do it even if there weren't paid for its--witness the open source movement which is largely funded by volunteer labor. Others see it as a job or a career path, but not much more. In my 25 year observation, those with this PASSION almost always get it, and those without it are usually left behind after the first few years into the profession. I think that the same can be said for secure coding / design. Not only do those people have a passion for coding / design, but the ones who seem to get it are the ones who have a passion for security as well. Okay, so probably no surprise here, right? Do what you enjoy and you'll excel at it more often than ones who do it out of other motives (no matter how noble--such as making an affordable living to provide for your family). So I agree with Ranum in a sense--that educational approaches to security have overall failed, but I think it is not because the educational process / system per se has failed us (not that I'm arguing that it couldn't be improved), but because we haven't been able to ignite the passion for security in others. (And frankly, I'm not even to what degree that's possible. I'll leave that to another discussion.) In the past two years, I've had the fortune to teach a computer security course that I had the major part in organizing / developing. I have learned two things about the students during that time: 1) All the students do well when it comes to rote memorization. (E.g., questions such as What cipher mode doesn't require an Initialization Vector?, etc.) 2) Only the students that seem to get it seem to do well on the questions requiring thought (i.e., ones requiring reasoning outside the box). Surprisingly (at least at first), I have often been discovered that those who other faculty members often consider the brightest students are ones who do the worst on the questions requiring thought. But in general, by the end of the 12 week period, I usually can tell who is going to take and try to apply what they learned and those who just chalk up the course as another 3 credit hours. I see what I think is a related phenomena in the commercial world as well. I've worked with a lot of developers who have worked on security-related software (e.g., firewalls, crypto, secure proxies, authentication and access control systems, etc.). One would EXPECT that the groups that work on these projects would as a whole do better at developing secure programs than the IT industry as a whole. But overall, I don't think that their batting average is all that much higher than the industry at large. We often hear excuses for this (security software is more complex, etc.), but I'm not buying it. If anything, it's this observation more than anything else that makes me think that formal education is not THE answer (although, I do think it is part of the answer). On a related note to security and education, I was wondering if anyone knows of any experimental data that shows that those with formal education in security develop more secure programs than those who have never had such formal training? If no such experimental data exists, why not? Can no one think of some formal,
RE: [SC-L] Interesting article on the adoption of Software Security
Dana Epp wrote...
[...snip...]
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. Especially on Windows and
the Linux platform. I am not trying to fuel the argument over which
language is better, it comes down to the right tool for the right job. I
know back in December ljknews suggested PL/I and Ada, but who has
actually seen production code in either Windows or Linux using it?
I suppose it's _possible_ that one might be able to sneak in a bit of
carefully constructed C++ in one of these kernels, but you'd probably
have to be very careful about what you used (e.g., probably most of
STL is out) and in the end, you'd probably have to use
extern C {
...
}
wrappers around most of your stuff so it could interface with the
rest of the kernel.
I thought of doing something like this back in 1990 when working on
device drivers with the Unix System V kernel at Bell Labs, but the
potential problems (several having to do with DTORs IIRC and the binding
issues) seemed to outweigh any potential gain. I thought of also using
C++ as a better (more strongly typed) C, but that too didn't seem
worth it.
Of course, there are some kernels that were implemented in C++; Clouds
comes to mind.
Lets face it. You aren't going to normally see Java or C# in kernel code
(yes I am aware of JavaOS and some guys at Microsoft wanting to write
everything in their kernel via managed code) but its just not going to
happen in practice. C and ASM is the right tool in this area of code.
I'd pretty much agree with this. You seldom even see Java or C# used in
real-time systems (and let's face it, the kernel itself is pretty much
real-time; don't want to be missing an interrupt while doing GC).
Perhaps once the Real-time Specification for Java is approved and
implemented by Sun, this will change, but I don't think that we'll
be seeing many new OSes adopt Java or C# for their kernel code.
(However, I think this also has to do in part with the fact that most
OS/kernel developers are not experts in OO...just my opinion.)
[...snip...]
Cripin is right; new code SHOULD be written in a type safe language
unless there is a very strong reason to do otherwise. The reality is
that many developers don't know when that right time is. And resulting
is poor choice in tools, languages and structure.
I think, in a large part, that's because your average developer knows
only one or maybe two programming languages. And if they know more,
they only know languages from a single paradigm (e.g., OO, logic programming,
functional programming, procedural, etc.). Because of this, the view is
when all you have is a hammer, everything looks like a nail.
I'd love for someone to show me... no... convince me, of a
typesafe language that can be used in such a place.
Not sure I get your drift here. Did you mean in commercial systems
or in OS kernels or something else? (Cut me some slack; I've only
had 2 cups of coffee so far. ;-)
I have yet to see it for production code, used on a regular basis.
Here at Qwest, we've been pretty much exclusively using nothing else
besides Java and C# since the last 6 years. (Java for about 6+ years
and C# for the past 2 years.)
So buffer overflows are pretty much things of the past, but developers
still don't validate most of their input data so there's still plenty
of XSS and SQL injection problems left. (IMO, these are just another
example of failure to do proper data validation, as are buffer overflows.)
[...snip...]
... Nor is right to assume you can use
typesafe languages as the panacea for secure coding.
To be sure, about 50% of the security holes that I still see are
the results of dumb design decisions (e.g., no authorization checks
whatsoever, placing sensitive data in persistent cookies, etc.).
Keeps my team plenty busy. ;-)
OTOH, I'm sure we'd be a lot worse off if developers here were still
allowed to use C or C++ to write new code in.
Cheers,
-kevin
---
Kevin W. Wall Qwest Information Technology, Inc.
[EMAIL PROTECTED] Phone: 614.215.4788
The reason you have people breaking into your software all
over the place is because your software sucks...
-- Former Whitehouse cybersecurity advisor, Richard Clarke,
at eWeek Security Summit
