CERIAS Weblogs » Infosec Education

Least privilege is the idea of giving a subject or process only the privileges it needs to complete a task. Compartmentalization is a technique to separate code into parts on which least privilege can be applied, so that if one part is compromised, the attacker does not gain full access. Why does this get confused all the time with separation of privilege? Separation of privilege is breaking up a *single* privilege amongst multiple, independent components or people, so that multiple agreement or collusion is necessary to perform an action (e.g., dual signature checks). So, if an authentication system has various biometric components, a component that evaluates a token, and another component that evaluates some knowledge or capability, and all have to agree for authentication to occur, then that is separation of privilege. It is essentially an “AND” logical operation; in its simplest form, a system would check several conditions before granting approval for an operation. Bishop uses the example of “su” or “sudo”; a user (or attacker of a compromised process) needs to know the appropriate password, and the user needs to be in a special group. A related, but not identical concept, is that of majority voting systems. Redundant systems have to agree, hopefully outvoting a defective system. If there was no voting, i.e., if all of the systems always had to agree, it would be separation of privilege. OpenSSH’s UsePrivilegeSeparation option is *not* an implementation of privilege separation by that definition, it simply runs compartmentalized code using least privilege on each compartment.

Update: additions added 4/19 and 4/24, at the end.

Back in 2002, Microsoft performed a “security standdown” that Bill Gates publicly stated cost the company over $100 million. That extreme measure was taken because of numerous security flaws popping up in Microsoft products, steadily chipping away at MS’s reputation, customer safety, and internal resources. (I was told by one MS staffer that response to major security flaws often cost close to $1 million each for staff time, product changes, customer response, etc. I don’t know if that is true, but the reality certainly was/is a substantial number.)

Without a doubt, people inside Microsoft took the issue seriously. They put all their personnel through a security course, invested heavily in new testing technologies, and even went so far as to convene an advisory board of outside experts (the TCAAB) — including some who have not always been favorably disposed towards MS security efforts. Security of the Microsoft code base suddenly became a Very Big Deal.

Fast forward 5 years: When Vista was released a few months ago, we saw lots of announcements that it was the most secure version of Windows ever, but that metric was not otherwise qualified; a cynic might comment that such an achievement would not be difficult. The user population has become habituated to the monthly release of security patches for existing products, with the occasional emergency patch. Bundling all the patches together undoubtedly helps reduce the overhead in producing them, but also serves to obscure how many different flaws are contained inside each patch set. The number of flaws maybe hasn’t really decreased all that much from years ago.

Meanwhile, reports from inside MS indicate that there was no comprehensive testing of personnel to see how the security training worked and no follow-on training. The code base for new products has continued to grow, thus opening new possibilities for flaws and misconfiguration. The academic advisory board may still exist, but I can’t find a recent mention of it on the Microsoft web pages, and some of the people I know who were on it (myself included) were dismissed over a year ago. The external research program at MSR that connected with academic institutions doing information security research seems to have largely evaporated — the WWW page for the effort lists John Spencer as contact, and he retired from Microsoft last year. The upcoming Microsoft Research Faculty Summit has 9 research tracks, and none of them are in security.

Microsoft seems to project the attitude that they have solved the security problem.

If that’s so, why are we still seeing significant security flaws appear that not only affect their old software, but their new software written under the new, extra special security regime, such as Vista and Longhorn? Examples such as the ANI flaw and the recent DNS flaw are both glaring examples of major problems that shouldn’t have been in the current code: the ANI flaw is very similar to a years-old flaw that was already known inside Microsoft, and the DNS flaw is another buffer overflow!! There are even reports that there may be dozens (or hundreds) of patches awaiting distribution for Vista.

Undoubtedly, the $100 million spent back in 2002 was worth something — the code quality has definitely improved. There is greater awareness inside Microsoft about security and privacy issues. I also know for a fact that there are a lot of bright, talented and very motivated people inside Microsoft who care about these issues. But questions remain: did Microsoft get its money’s worth? Did it invest wisely and if so, why are we still seeing so many (and so many silly) security flaws? Why does it seem that security is no longer a priority? What does that portend for Vista, Longhorn, and Office 2007? (And if you read the “standdown” article, one wonders also about Mr. Nash’s posterior. )

I have great respect for many of the things Microsoft has done, and admiration for many of the people who work there. I simply wish they had some upper management who would realize that security (and privacy) are ongoing process needs, not one-time problems to overcome with a “campaign.”

What do you think?

[posted with ecto]

Update 4/19: The TCAAB does still continue to exist, apparently, but with a greater focus on privacy issues than security. I do not know who the current members might be.

Update 4/24: I have heard (informally) from someone inside Microsoft in informal response to this post. He pointed out several issues that I think are valid and deserve airing here;

1. Security training of personnel is on-going. It still is unclear to me whether they are employing good educational methods, including follow-up testing, to optimize their instruction.
2. The TCABB does indeed continue (and was meeting when I made the original post!). It has undergone some changes since it was announced, but is largely the same as when it was formed. What they are doing, and what effect they are having (if any), is unclear.
3. Microsoft’s patch process is much smoother now, and bundled patches are easier to apply than lots of individual ones. (However, there are still a lot of patches for things that shouldn’t be in the code.)
4. The loss of outreach to academia by MSR does not imply they aren’t still doing research in security issues.

Many of my questions still remain unanswered, including Mr. Nash’s condition….

Note: I’ve updated this article after getting some feedback from Alexander Limi.

A colleague of mine who is dealing with Plone, a CMS system built atop Zope, pointed me to a rather disturbing document in the Plone Documentation system, one that I feel is indicative of a much larger problem in the web app dev community.

The first describes a hole (subsequently patched) in Plone that allowed users to upload arbitrary JavaScript. Apparently no input or output filtering was being done. Certainly anyone familiar with XSS attacks can see the potential for stealing cookie data, but the article seems to imply this is simply a spam issue:

Clean up link spam

Is this a security hole?
No. This is somebody logging in to your site (if you allow them to create their own users) and adding content that can redirect people to a different web site. Your server, site and content security is not compromised in any way. It’s just a slightly more sophisticated version of comment spam. If you open up your site to untrusted users, there will always be a certain risk that people add content that is not approved. It’s annoying, but it’s not a security hole.

Well, yes, actually, it is a security hole. If one can place JavaScript on your site that redirects the user to another page, they can certainly place JavaScript on your site that grabs a user’s cookie data and redirects that to another site. Whether or not they’ll get something useful from the data varies from app to app, of course. What’s worrisome is that it appears as if one of Plone’s founders (the byline on this document is for Alexander Limi, whose user page describes him as “one of Plone’s original founders.”) doesn’t seem to think this is a security issue.

After getting feedback from Alexander Limi, it seems clear that he does understand the user-level security implications of the vulnerability, but was trying to make the distinction that there was no security risk to the Plone site itself. Still, the language of the document is (unintentionally) misleading, and it’s very reminiscent of the kinds of misunderstandings and excuses I see all the time in open-source web app development.

The point here is (believe it or not) not to pick on Plone. This is a problem prevalent in most open source development (and in closed source dev, from my experience). People who simply shouldn’t be doing coding are doing the coding — and the implementation and maintenance.

Let’s be blunt: A web developer is not qualified to do the job if he or she does not have a good understanding of web application security concepts and techniques. Leaders of development teams must stop allowing developers who are weak on security techniques to contribute to their products, and managers need to stop hiring candidates who do not demonstrate a solid secure programming background. If they continue to do so, they demonstrate a lack of concern for the safety of their customers.

Educational initiatives must be stepped up to address this, both on the traditional academic level and in continuing education/training programs. Students in web development curriculums at the undergrad level need to be taught the importance of security and effective secure programming techniques. Developers in the workforce today need to have access to materials and programs that will do the same. And the managerial level needs to be brought up to speed on what to look for in the developers they hire, so that under-qualifed and unqualified developers are no longer the norm on most web dev teams.

The newest version of PHPSecInfo, version 0.2, is now available. Here are the major changes:

• Added link to “more info” in output. These lead to pages on the phpsec.org site giving more details on the test and what to do if you have a problem
• Modified CSS to improve readability and avoid license issue with PHP (the old CSS was derived from the output of phpinfo())
• New test: PhpSecInfo_Test_Session_Save_Path
• Added display of “current” and “recommended” settings in test result output
• Various minor changes and bug fixes; see the CHANGELOG for details

-Download now

-Join the mailing list

I haven’t posted an update lately of new content on our site, so here’s a bit of a make-up post:

CERIAS Reports & Papers

• "Rights Protection for Categorical Data"
  17 January 2007, 11:00 pm
• "Privacy-Preserving Credit Checking"
  17 January 2007, 11:00 pm
• "Security in Wireless Sensor Networks - A Layer based Classification"
  22 January 2007, 11:00 pm

CERIAS Hotlist

• Plynt Penetration Testing Learning Center
  31 January 2007, 7:09 am
• FireMon by Secure Passage - Firewall and security device change control, auditing and optimization.
  29 January 2007, 9:10 am

CERIAS News

• Biometrics Lab: Brown Bag Lunches Highlight Recent Research
  25 January 2007, 9:32 am
• Call for Presentations: Midwest Security Workshop at Purdue
  8 February 2007, 10:22 am
• Registration Open: Columbus Incident Response Workshop (CCIR)
  15 February 2007, 2:40 pm
• Purdue Partners with LPD in Cyber Forensics
  19 February 2007, 1:09 pm

CERIAS Security Seminar Podcast

• Vipin Swarup, "Research Challenges in Assured Information Sharing"
  17 January 2007, 3:30 pm
• Wojciech Szpankowski, "WHAT IS INFORMATION?"
  24 January 2007, 3:30 pm
• Chris Clifton, "Mathematically Defining Privacy"
  31 January 2007, 3:30 pm

This talk by Marcus MacNeill (Surgient) discussed the Surgient Virtual Training Lab used by CERT-US to train military personnel in security best practices, etc… I was disappointed because the talk didn’t discuss the challenges of teaching security, and the lessons learned by CERT doing so, but instead focused on how the product could be used in a teaching environment. Not surprisingly, the Surgient product resembles both VMware’s lab manager and ReAssure. However, the Surgient product doesn’t support the sharing of images, and stopping and restarting work, e.g. development work by users (from what I saw — if it does it wasn’t mentioned). They mentioned that they had patented technologies involved, which is disturbing (raise your hand if you like software patents). ReAssure meets (or will soon, thanks to the VIX API) all of the requirements he discussed for teaching, except for student shadowing (seeing what a student is attempting to do). So, I would be very interested in seeing teaching labs using ReAssure as a support infrastructure. There are of course other teaching labs using virtualization that have been developed at other universities and colleges; the challenge is of course to be able to design courses and exercises that are portable and reusable. We can all gain by sharing these, but for that we need a common infrastructure where all these exercises would be valid.

We’ve made some significant changes to how people can view our Security Seminar Series:

• We’re now offering h.264/mp4 versions of the seminar videos, both as downloadable files and in a spanking-new video podcast. Look us up in iTunes or the Democracy channel guide, and you’ll find us. The 320×240 videos are not only higher-quality than what we’ve previously offered, but are also playable on portable players than support h.264 (we’ve tested it on 5G iPods)
• We will also look at encoding all of our previous recorded seminars to h.264/mp4 in the next few months. Those that we have on DVD will be easy, but the ones more than a couple years old we only have on VHS, so they will likely take a lot longer.
• In the near future — at latest by summer 2007 — we will stop encoding our videos in RealMedia format. The popularity of Real has faded a lot over the years, and most folks (including us) aren’t interested in installing it. This would leave us without a streaming video format, but we’re not sure there’s a lot of demand for one now. If there is, we will likely go with an embedded Flash video player rather than something like Windows Media.

If there is strong interest in providing other video formats, please let us know. We may consider moving to 640×480 resolution for our videos now that iPods support the larger size, but we don’t want to push the file size to high and make for lengthy downloads.

If you have problems or feedback, please let us know in the comments section.

So who’s going to OSCON 2006?  I am, and if you are too, drop me a line so we can meet up.  I’m also going to be “moderating” a PHP Security BOF meet, so if you have some interest in PHP Security or secure web dev in general, come by and participate in the chaos.

If you’re planning on going, make sure to check out the official wiki and the OSCamp wiki.

CERIAS is pleased to announce the launch of a new initiative to increase the security of K-12 information systems nationwide. We’ve developed a comprehensive set of self-paced multimedia training modules for K-12 educators and support staff titled Keeping Information Safe: Practices for K-12 Schools. The goal of these modules is to increase the security of K-12 school information systems and the privacy of student data by increasing teacher awareness of pertinent threats and vulnerabilities as well as their responsibilities in keeping information safe.

The modules are available for free for K-12 teachers, institutions, and outreach organizations.

I was involved in disclosing a vulnerability found by a student to a production web site using custom software (i.e., we didn’t have access to the source code or configuration information). As luck would have it, the web site got hacked. I had to talk to a detective in the resulting police investigation. Nothing bad happened to me, but it could have, for two reasons.

The first reason is that whenever you do something “unnecessary”, such as reporting a vulnerability, police wonder why, and how you found out. Police also wonders if you found one vulnerability, could you have found more and not reported them? Who did you disclose that information to? Did you get into the web site, and do anything there that you shouldn’t have? It’s normal for the police to think that way. They have to. Unfortunately, it makes it very uninteresting to report any problems.

A typical difficulty encountered by vulnerability researchers is that administrators or programmers often deny that a problem is exploitable or is of any consequence, and request a proof. This got Eric McCarty in trouble — the proof is automatically a proof that you breached the law, and can be used to prosecute you! Thankfully, the administrators of the web site believed our report without trapping us by requesting a proof in the form of an exploit and fixed it in record time. We could have been in trouble if we had believed that a request for a proof was an authorization to perform penetration testing. I believe that I would have requested a signed authorization before doing it, but it is easy to imagine a well-meaning student being not as cautious (or I could have forgotten to request the written authorization, or they could have refused to provide it…). Because the vulnerability was fixed in record time, it also protected us from being accused of the subsequent break-in, which happened after the vulnerability was fixed, and therefore had to use some other means. If there had been an overlap in time, we could have become suspects.

The second reason that bad things could have happened to me is that I’m stubborn and believe that in a university setting, it should be acceptable for students who stumble across a problem to report vulnerabilities anonymously through an approved person (e.g., a staff member or faculty) and mechanism. Why anonymously? Because student vulnerability reporters are akin to whistleblowers. They are quite vulnerable to retaliation from the administrators of web sites (especially if it’s a faculty web site that is used for grading). In addition, student vulnerability reporters need to be protected from the previously described situation, where they can become suspects and possibly unjustly accused simply because someone else exploited the web site around the same time that they reported the problem. Unlike security professionals, they do not understand the risks they take by reporting vulnerabilities (several security professionals don’t yet either). They may try to confirm that a web site is actually vulnerable by creating an exploit, without ill intentions. Students can be guided to avoid those mistakes by having a resource person to help them report vulnerabilities.

So, as a stubborn idealist I clashed with the detective by refusing to identify the student who had originally found the problem. I knew the student enough to vouch for him, and I knew that the vulnerability we found could not have been the one that was exploited. I was quickly threatened with the possibility of court orders, and the number of felony counts in the incident was brandished as justification for revealing the name of the student. My superiors also requested that I cooperate with the detective. Was this worth losing my job? Was this worth the hassle of responding to court orders, subpoenas, and possibly having my computers (work and personal) seized? Thankfully, the student bravely decided to step forward and defused the situation.

As a consequence of that experience, I intend to provide the following instructions to students (until something changes):

1. If you find strange behaviors that may indicate that a web site is vulnerable, don’t try to confirm if it’s actually vulnerable.
2. Try to avoid using that system as much as is reasonable.
3. Don’t tell anyone (including me), don’t try to impress anyone, don’t brag that you’re smart because you found an issue, and don’t make innuendos. However much I wish I could, I can’t keep your anonymity and protect you from police questioning (where you may incriminate yourself), a police investigation gone awry and miscarriages of justice. We all want to do the right thing, and help people we perceive as in danger. However, you shouldn’t help when it puts you at the same or greater risk. The risk of being accused of felonies and having to defend yourself in court (as if you had the money to hire a lawyer — you’re a student!) is just too high. Moreover, this is a web site, an application; real people are not in physical danger. Forget about it.
4. Delete any evidence that you knew about this problem. You are not responsible for that web site, it’s not your problem — you have no reason to keep any such evidence. Go on with your life.
5. If you decide to report it against my advice, don’t tell or ask me anything about it. I’ve exhausted my limited pool of bravery — as other people would put it, I’ve experienced a chilling effect. Despite the possible benefits to the university and society at large, I’m intimidated by the possible consequences to my career, bank account and sanity. I agree with HD Moore, as far as production web sites are concerned: “There is no way to report a vulnerability safely”.

Edit (5/24/06): Most of the comments below are interesting, and I’m glad you took the time to respond. After an email exchange with CERT/CC, I believe that they can genuinely help by shielding you from having to answer questions from and directly deal with law enforcement, as well as from the pressures of an employer. There is a limit to the protection that they can provide, and past that limit you may be in trouble, but it is a valuable service.