Re: Reliance on Microsoft called risk to U.S. security
On Wed, Oct 01, 2003 at 07:02:00PM -0700, bear wrote: Heh. You looked at my mail headers, didn't you? Yes, I use pine - primarily *because* of that property. It treats all incoming messages as text rather than live code. A protocol for text (as opposed to live code) requires compliant clients (ie, clients that don't do anything other than display the recieved messages). As such, it's at least somewhat a social issue. While I agree that text is far safer than html or a .exe, do you run Pine on a dumb terminal, or in a window? If the latter, escape sequences which most folks would class as text can lead to remote compromise. There have been occasional bugs in terminal emulators, in X and others. TERM=vt100 is in some sense defining an interpreted programming language, albeit a limited one. That absolute safety is impossible does not excuse software from our favorite vendor whose security model is all but impossible to fathom, so I'm not at all disagreeing with your point. I use Mutt. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Reliance on Microsoft called risk to U.S. security
From: bear [EMAIL PROTECTED] Heh. You looked at my mail headers, didn't you? Yes, I use pine - primarily *because* of that property. It treats all incoming messages as text rather than live code. BUGTRAQ in the last 3 years lists over 80 mails on pine - including reference to this recently: http://www.idefense.com/advisory/09.10.03.txt which also appears in candidates on cve.mitre.org. (Mitre seem to take unreasonable time in converting candidates to definite problems unless I'm misunderstanding their website.) [HTML mail] can cause your machine, specifically, to make network connections to get graphics, style sheets, etc, and will not display That could include web bugs for spammers. I agree it's ridiculous to read mail in a browser but a conventional MUA has risks too. I write all mail to disk and view it with my favourite text editor. This is convenient with practice. Now I only want MUAs for sending mail (it's worth it to get the correct references in my reply headers). I use this script on one of my accounts where I accept HTML mail (reluctantly from a hotmail user). http://www.notatla.org.uk/SOFTWARE/text_lover_mail_filter.plx The HTML conversion is done by lynx (confined by SubDomain). This practice can result in running mimencode -u and metamail -w on a few things. It's not that common for a non-text message to get past my procmail rules and have me choose to read it. This is all pretty simple but certainly not mass-market. I must order a told you so rubber stamp for when my monocultural acquaintances get hacked. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Don't kill the messenger (was: Re: Reliance on Microsoft called risk to U.S. security)
On Wednesday 01 October 2003 22:02, bear wrote: No, it is not. You can make a hyperdocument that is completely self-contained and therefore text, but that is not how HTML is normally made. HTML can cause your machine to do things other than display it, and to that extent it is code, not text. A small nit: HTML is, in fact, text. The effects you describe are the result of a client taking certain actions based on the text/html MIME type. That's the reason you use Pine (and I use Kmail). These clients (and others... yay, elm!) don't take unbidden actions to render HTML mail or cause executable attachments to execute. You can't rely on saving an HTML document and being able to read it years or decades later, because with hypertext, maybe the part you're interested in (or need for evidence) isn't even on the page you saved. True, but again, that's a property of HTML. That the HTML document was transmitted through mail is a side issue. It's not that email has been overloaded, through the use of MIME, to carry content other than text/plain. The problem is that certain MUAs have been built to take some default actions based on the MIME types received, and those clients have become (for whatever reason) popular among mail users of a, shall we say, non-technical bent. The fact that sending HTML (and other code) through SMTP was not considered a violation of SMTP has allowed a generation of mail readers to become common that encourage mail viruses, macroviruses, worms, and other malicious code. If we are interested in security, we need some kind of protocol where we as a group just draw a line and say nothing but text through this port. SMTP is *already* such a protocol. Base-64 encoding (and UUENCODE before it) was designed to address the 7-bit gateway through which email once passed. MIME only describes and encapsulates non-textual content. (the first M originally stood for 'multimedia', not 'multipurpose') Some mail clients have evolved (or been designed *cough*outlook*cough*) to be infection vectors, but that's not the fault of the base transport protocol. It's the result of poor security decisions in the client design process. This is not to demonize MIME, either. Some applications, like PGP signatures, are elegant uses. Much better than the X-PGP-Signature header I was helping develop 10 years ago. There's nothing intrinsically wrong with extending mail to carry arbitrary content. The problem appears when the MUA is able to take some risky action with that content, whether automatically or through unwise user action. Grandma clicks on everything. Mail as a vulnerability is a client issue and a training issue. That said, I also despise HTML mail for all the reasons you describe. But between the September That Never Ended and the release of Mosaic, it's really no surprise that eye candy has become an imperative. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Reliance on Microsoft called risk to U.S. security
| Can be relied on to _only_ deliver text is a valuable and important | piece of functionality, and a capability that has been cut out of too | many protocols with no replacement in sight. While I agree with the sentiment, the text/code distinction doesn't capture what's important. Is HTML text or code? Well ... it's actually neither. There is a set of tags in HTML that is perfectly safe. Setting fonts and font colors, describing a table ... all kinds of stuff like that isn't text, but it can't hurt you either. (Whether these are *useful* in mail is a whole other question) On the other hand, embedded references that reach out over the network are inherently dangerous, since the very act of autonomously opening a connection to a system of someone else's choosing is something I, personally, don't want my mail reader doing, ever. Text is code, too! A plain ASCII message received by Pine is run through the Pine Interpretation Engine - the Pine MUA under another name. Some character sequences cause entries to be made into a list of subject lines. Others may trigger automatic refiling. Most cause bits to be written to a terminal window. Those bits in turn are really code, interpreted by my xterm (or whatever), causing it do to all kinds of complicated things that ultimately light some pixels on my screen. The real distinction is: Which of *my* resources are *you* able to manipulate by sending me mail? I'm willing to give you complete access to send characters to the terminal in which pine runs ... well, almost. There's a long history of security holes *in terminals* - e.g., escape sequences that load the WRU buffer, and then a control character that causes the WRU to send back qyy|rm *\n! You have to carry this analysis *all the way through all the levels of interpretation*. Way back, when I worked on designing terminals at DEC, we were aware of the security issues and it was a design rule that there was no way to send characters to the terminal and have exactly those read back automatically. (Usually, you couldn't read it back at all. Otherwise, they were wrapped up in a format that would be innocuous to all but very strange programs - e.g., as a hex string.) It was fun evaluating competitor's terminals against that design rule - almost all of them failed. (It was not so much fun telling marketing that no, we would not implement that particular feature even though the competition had it.) Anyhow ... if you consider the entire *system*, then the rule is that I will give you complete access to write a certain safe subset of ASCII characters, or a safe subset of ASCII characters plus escape sequences. That's why mail clients have long filtered out certain characters. (An MUA that talks direct X calls has no reason to filter anything, since writing a text string directly with X goes into an interpreter that can change *only* the bits on the screen.) A resource-based model gives you some basis for deciding which parts of HTML are acceptable, and which are not. Given such a model, it's perfectly possible to write a safe HTML interpreter. Of course, you lose some features - that's life. Life would also be much easier if you never had to lock your door because no one would ever think of stealing. BTW, a resource model has to change with time. The traditional view has been that I grant anyone full write access to the end of mail file - i.e., anyone can send me as much mail as they like. These days, I really *don't* want to grant that access to spammers - and spam blocking techniques are all about how to control the SMTP interpreter I present to the outside world to protect my disk resources. -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Reliance on Microsoft called risk to U.S. security
Peter has raised a number of important points. Let me start by saying that I do not see a strong distinction between a file to be viewed and a program. Both are instructions to the computer to perform some actions. While we might think the renderer showing us flat ASCII text is quite trustworthy, our degree of trust in an HTML should be less, and we shouldn't trust a Word format renderer at all (thanks to Word Macro viruses). At 9:21 PM -0700 9/30/03, Peter Gutmann wrote: Bill Frantz [EMAIL PROTECTED] writes: The real problem is that the viewer software, whether it is an editor, PDF viewer, or a computer language interpreter, runs with ALL the user's privileges. If we ran these programs with a minimum of privilege, most of the problems would just go away. This doens't really work. Consider the simple case where you run Outlook with 'nobody' privs rather than the current user privs. You need to be able to send and receive mail, so a worm that mails itself to others won't be slowed down much. I do not envision running either programs or viewers under the privileges of the mail agent. Since I am not really a Unix person, let me take a stab at a design and let the people who know what they are doing take stabs at it. What we need is an environment of very limited privilege to use to confine our untrusted code. Specifically: * No ability to make connections to other services, either over the network or locally. (I think this item requires a kernel change.) * Very limited access to the file system. We might take the view that since we control all the ways the confined process can send data out of the system, it can have full read-only access to the file system without risking anything important. I am told we can build general limits of file system access with chroot, but I am also told that processes can break out of these limits. This is an area where I would love to learn more. * We can pass in the privileges we think the process should have via open file handles. These will probably include the ability to render on a portion of the screen, and the ability to get mouse and keyboard focus. (We need a way for trusted code to mediate these accesses so the user can have a secure attention function.) * Strict control of other communication paths I haven't thought of. :-) In addition everyone's sending you HTML-formatted mail, so you need access to (in effect) MSIE via the various HTML controls. An HTML renderer should be able to run in the above environment. Further, you need Word and Excel and Powerpoint for all the attachments that people send you. For viewing Word etc. documents, the applications should run in the above environment. The interesting case is where someone has sent you something like a Word document and asked you to mark it up. Everything should proceed well in the above until it comes time to save a local copy or mail the changed document back. http://www.combex.com/papers/darpa-report/html/ describes the Powerbox pattern for allowing the user to specify an output file for a confined process such as we are discussing. I would think the best way to return such a file in Unix would be as an open file handle. However I don't know of a way for a program to call a service with greater privilege than it has and accept a return value unless that service is part of the kernel. Perhaps some Unix experts can come up with ideas. As for mailing the document back, if the mail agent gave the confined program read-write access to a copy of the file, the confined program could write its output over the input and the mail agent could then make that file available to the user when the confined program returns, and the user could include it in the reply email. They need access to various subsystems like ODBC and who knows what else as an extension of the above. Since most users do not have these facilities running on their machines, I suspect that most Word/Excel/Powerpoint files would render quite well from a confined process. I would say that having random, perhaps hostile, files able to update my local data bases is a violation of my security policy. As you follow these dependencies further and further out, you eventually end up running what's more or less an MLS system where you do normal work at one privilege level, read mail at another, and browse the web at a third. This was tried in the 1970s and 1980s and it didn't work very well even if you were prepared to accept a (sizeable) loss of functionality in exchange for having an MLS OS, and would be totally unacceptable for someone today who expects to be able to click on anything in sight and have it automatically processed by whatever app is assigned to it. UIs have changed considerably since the 1980s. It turns out that modern UIs make it much easier for users to run programs with only the privileges they need than the UIs of the 80s. (See the email thread at
Re: Reliance on Microsoft called risk to U.S. security
Bill Frantz [EMAIL PROTECTED] writes: The real problem is that the viewer software, whether it is an editor, PDF viewer, or a computer language interpreter, runs with ALL the user's privileges. If we ran these programs with a minimum of privilege, most of the problems would just go away. This doens't really work. Consider the simple case where you run Outlook with 'nobody' privs rather than the current user privs. You need to be able to send and receive mail, so a worm that mails itself to others won't be slowed down much. In addition everyone's sending you HTML-formatted mail, so you need access to (in effect) MSIE via the various HTML controls. Further, you need Word and Excel and Powerpoint for all the attachments that people send you. They need access to various subsystems like ODBC and who knows what else as an extension of the above. As you follow these dependencies further and further out, you eventually end up running what's more or less an MLS system where you do normal work at one privilege level, read mail at another, and browse the web at a third. This was tried in the 1970s and 1980s and it didn't work very well even if you were prepared to accept a (sizeable) loss of functionality in exchange for having an MLS OS, and would be totally unacceptable for someone today who expects to be able to click on anything in sight and have it automatically processed by whatever app is assigned to it. Even if you could somehow enforce the MLS-style restrictions and convince people to run an OS with this level of security enabled, the outcome when this was tried with MLS OSes was that users would do everything possible to bypass it because it was seen as an impediment to getting any work done: SIGMA eventually allowed users to violate the *-property to avoid them having to re- type messages at lower security levels (i.e. it recognised that they were going to violate security anyway, so it made it somewhat less awkward to do), Multics and GEMSOS allowed users to be logged in at multiple security levels to get work done (now add the 1,001 ways that Windows can move data from A to B to see how much harder this is to control than on a 1970s system where the only data-transfer mechanism was copy a file), KSOS used non-kernel security-related functions (kludges) to allow users to violate security properties and get their work done, etc etc. One thing that I noticed in the responses to CyberInsecurity: The Cost of Monopoly was that of the people who criticised it as recommending the wrong solution, no two could agree on any alternative remedy. This indicates just how hard a problem this really is... Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Reliance on Microsoft called risk to U.S. security
On Wed, 1 Oct 2003, Peter Gutmann wrote: This doens't really work. Consider the simple case where you run Outlook with 'nobody' privs rather than the current user privs. You need to be able to send and receive mail, so a worm that mails itself to others won't be slowed down much. In addition everyone's sending you HTML-formatted mail, so you need access to (in effect) MSIE via the various HTML controls. Further, you need Word and Excel and Powerpoint for all the attachments that people send you. They need access to various subsystems like ODBC and who knows what else as an extension of the above. As you follow these dependencies further and further out, you eventually end up running what's more or less an MLS system where you do normal work at one privilege level, read mail at another, and browse the web at a third. This was tried in the 1970s and 1980s and it didn't work very well even if you were prepared to accept a (sizeable) loss of functionality in exchange for having an MLS OS, and would be totally unacceptable for someone today who expects to be able to click on anything in sight and have it automatically processed by whatever app is assigned to it. I think part of the point is that that expectation is a substantial problem. Data that moves between machines is inherently suspect; and if it can originate at unknown machines (as in SMTP or NNTP), it should be regarded as guilty until proven innocent. There ought to be no way to send live code through the mail. Users simply cannot be expected to have the ability to make an informed decision (as opposed to a habit) about whether to run it, because its format does not give them enough information to make an informed decision. The distinction between live code and text is crucial. While both are just sequences of bytes, text has no semantics as far as the machine is concerned. Once you start sending something that has machine semantics - something that contains instructions for the machine to run and running those instructions may cause the machine to do something besides just displaying it - then you are dealing with live code. And live code is handy, but dangerous. There is pressure to stick live code into any protocol that moves text; SMTP sprouted 'clickable' attachments. Java, javascript, and now flash seem to have gotten stuck into HTTP. But I think that live code really and truly needs a different set of protocols; and for security's sake, there really need to be text-only protocols. It should be part of their charter and part of their purpose that they do *NOT* under any circumstances deliver live code. Can be relied on to _only_ deliver text is a valuable and important piece of functionality, and a capability that has been cut out of too many protocols with no replacement in sight. Separating it by protocol would give people practical things that they could do. You could, for example, allow people to use a live-code mail protocol inside a company firewall or allow a live-code browsing protocol inside the firewall, while allowing only a text mail protocol or a text browsing protocol to make connections from outside the company. We approximate this by trying to make smarter clients that have different trust models for different domains, but that's always a crapshoot; you then have to depend on a client, and if the client can be misconfigured and/or executes live code it can't really be relied on. It would be better to have separate protocols; Ideally, even separate applications. One thing that I noticed in the responses to CyberInsecurity: The Cost of Monopoly was that of the people who criticised it as recommending the wrong solution, no two could agree on any alternative remedy. This indicates just how hard a problem this really is... Indeed. I think that there ought to be simpler, text-only protocols for the use of people who don't need to send and recieve live code, so that they could be effectively protected from live code at the outset unless they really need it. Others, of course, disagree. Bear - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Reliance on Microsoft called risk to U.S. security
Jeroen C.van Gelderen wrote: On Saturday, Sep 27, 2003, at 15:48 US/Eastern, [EMAIL PROTECTED] wrote: You have not met my users! Indeed, but I'm here to learn :) ... something is wrong. Why would she click YES? ... Because I'm an optimist I believe that Alice will read the dialog and err on the side of caution. Maybe that isn't realistic. ... I agree that such composition must be intuitive or we cannot expect it to work. I think that CapDesk is a nice publicly available prototype of a workable capability desktop. It would be very interesting to see your assessment on whether a CapDesk approach would be workable for your users. And if it isn't, why not. I hope you can lend your experience. OK, I'll lend mine. With my ISP hat on, the vast majority of support calls have to do with users ignoring the content of M$ dialog boxes, hitting YES or OK, then calling when things don't work. Admittedly, the text in those dialog boxes isn't particularly useful. But this costs us a lot of good old hard cash. Or with my personal hat, my 15-year-old niece had an infected machine. Actually a multiply infected machine. Took me several hours to clean up. And then I watched her check her yahoo mail, and click yes on the very next Norton/McAfee dialog box, reinfecting her Comcast connected machine before my very eyes. Why, I asked? I just spent a lot of time fixing your machine, and explained what had gone wrong. She says, That message came from my best friend at school. Of course it didn't. But it probably came from another friend with them both in the address book. And social engineering is a lot more powerful than any amount of training, no matter how very recent! The answer to a technical problem is _not_ depending on user caution! -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Reliance on Microsoft called risk to U.S. security
On Saturday, Sep 27, 2003, at 20:31 US/Eastern, Zooko wrote: Jeroen C. van Gelderen [EMAIL PROTECTED] wrote: There is no way around asking the user because he is the ultimate authority when it comes to making trust decisions. (Side-stepping the issues in a (corporate) environment where the owner of the machine is entitled to restrict its users in any way he sees fit. The point is that the software agent cannot make trust decisions.) ... but you don't always have to *ask* the user, if instead you can infer from actions that the user already performs. Oops, I didn't mean to imply that you'd have to ask as much as happens at present! Automatically inferring is pretty much required if Alice is to be able to do a whole day's worth of work without seeing any popups in the steady case. You only ask Alice when you cannot otherwise reliably infer her intentions; That will be necessary at some point. The remaining questions that do get asked then are meaningful and do not condition towards a knee-jerk Click-Yes reaction. I used to think that a capability desktop would be severely hobbled by the requirement that the user state a plethora of privilege rules, until I saw Marc Stiegler's CapDesk demo at the second O'Reilly Emerging Technologies conference. In that demo, a perfectly familiar desktop with File - Open and File - Save As dialogs also serves as a Least-Privilege-enforcing access control system which protects even a naive and lazy user from a malicious text editor. And you can even download and try it for yourself as all of CapDesk is freely available. If that is too much, just download Marc's video demonstration [1]: http://www.erights.org/talks/skynet/index.html I truly don't know how much more helpful one can get in order to dispel the perpetuation of these security myths? See also Ping Yee's research in secure Human Interface. http://www.sims.berkeley.edu/~ping/sid/ -J [1] I don't know why the video is available in M$ proprietary format only though :( - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Reliance on Microsoft called risk to U.S. security
At 8:12 AM -0700 9/27/03, [EMAIL PROTECTED] wrote: On Fri, 26 Sep 2003, Bill Frantz wrote: The real problem is that the viewer software, whether it is an editor, PDF viewer, or a computer language interpreter, runs with ALL the user's privileges. If we ran these programs with a minimum of privilege, most of the problems would just go away. And what privileges should the Perl interpreter run with when I click on a .pl file? How would the graphical shell know what privileges to assign to each file? Given a strange program that has just arrived on my machine, my current policy is not to run it at all. I might be willing to adopt a policy of giving it a small amount of memory, CPU, and some space to render on the screen. That would allow people to exchange active amusements with a degree of safety. If the program required more privilege (for example, a new version of a utility from a co-worker), I would be happy to move it to an environment where it had the resources it needs to run. On the other hand a *trivial* privilege system: View (zero privs) vs. Run (full privs) is viable, and is one of the pre-requisites for a more secure UI, along with the previously discussed trusted path issues, non-spoofing of the security interface, ... Limiting the privilege of the View program would provide protection against flaws in the viewer. Given the number of flaws in very basic software, such protection seems of have real value. Cheers - Bill - Bill Frantz| There's nothing so clear as | Periwinkle (408)356-8506 | vague idea you haven't written | 16345 Englewood Ave www.pwpconsult.com | down yet. -- Dean Tribble | Los Gatos, CA 95032 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Reliance on Microsoft called risk to U.S. security
On Fri, 26 Sep 2003, Bill Frantz wrote: The real problem is that the viewer software, whether it is an editor, PDF viewer, or a computer language interpreter, runs with ALL the user's privileges. If we ran these programs with a minimum of privilege, most of the problems would just go away. And what privileges should the Perl interpreter run with when I click on a .pl file? How would the graphical shell know what privileges to assign to each file? Also security is not closed under composition, two individually secure components can combine to produce an insecure system. I think that no such secure *non-trivial* least privilege system exists for a graphical general purpose computer either in theory, or in practice. On the other hand a *trivial* privilege system: View (zero privs) vs. Run (full privs) is viable, and is one of the pre-requisites for a more secure UI, along with the previously discussed trusted path issues, non-spoofing of the security interface, ... -- Victor Duchovni IT Security, Morgan Stanley - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Reliance on Microsoft called risk to U.S. security
On Saturday, Sep 27, 2003, at 11:12 US/Eastern, [EMAIL PROTECTED] wrote: On Fri, 26 Sep 2003, Bill Frantz wrote: The real problem is that the viewer software, whether it is an editor, PDF viewer, or a computer language interpreter, runs with ALL the user's privileges. If we ran these programs with a minimum of privilege, most of the problems would just go away. And what privileges should the Perl interpreter run with when I click on a .pl file? How would the graphical shell know what privileges to assign to each file? Could it not ask the user? My Apple regularly asks for decisions of this sort, and remembers the results. So do (popular firewall) products on the PC. Now, most of these questions are too technical in nature but point remains that asking question and remembering the answer is possible. I continue to believe that few users would grant an email message access to both the Internet and the Address Book when they are asked those two questions, provided that the user had not been conditioned to clicking YES in order to get any work done at all. There is no way around asking the user because he is the ultimate authority when it comes to making trust decisions. (Side-stepping the issues in a (corporate) environment where the owner of the machine is entitled to restrict its users in any way he sees fit. The point is that the software agent cannot make trust decisions.) Also security is not closed under composition, two individually secure components can combine to produce an insecure system. I think that no such secure *non-trivial* least privilege system exists for a graphical general purpose computer either in theory, or in practice. Are you familiar with the KeyKOS and EROS operating systems and/or Stiegler's CapDesk, a secure desktop in Java? They are all based on the Principle Of Least Privilege (trough capabilities) and they manage to preserve security in the face of composition. Do you consider those systems to be trivial, or broken? What is the reason these systems cannot exist in theory or practice? http://www.combex.com/tech/edesk.html http://www.erights.org/talks/skynet/index.html http://www.cis.upenn.edu/~KeyKOS/ http://www.eros-os.org/ On the other hand a *trivial* privilege system: View (zero privs) vs. Run (full privs) is viable, and is one of the pre-requisites for a more secure UI, along with the previously discussed trusted path issues, non-spoofing of the security interface, ... -J - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Reliance on Microsoft called risk to U.S. security
On Sat, 27 Sep 2003, Jeroen C.van Gelderen wrote: I continue to believe that few users would grant an email message access to both the Internet and the Address Book when they are asked those two questions, provided that the user had not been conditioned to clicking YES in order to get any work done at all. You have not met my users! This is really rather naive. Users don't understand pop dialogues, they raise their stress level, always clicking yes makes the problem go away. There is no way around asking the user because he is the ultimate authority when it comes to making trust decisions. (Side-stepping the issues in a (corporate) environment where the owner of the machine is entitled to restrict its users in any way he sees fit. The point is that the software agent cannot make trust decisions.) See above. Also security is not closed under composition, two individually secure components can combine to produce an insecure system. I think that no such secure *non-trivial* least privilege system exists for a graphical general purpose computer either in theory, or in practice. Are you familiar with the KeyKOS and EROS operating systems and/or Stiegler's CapDesk, a secure desktop in Java? They are all based on the Principle Of Least Privilege (trough capabilities) and they manage to preserve security in the face of composition. Do you consider those systems to be trivial, or broken? What is the reason these systems cannot exist in theory or practice? What fraction of real users will be able to use these systems? Will users really understand the composition properties of security policies? -- Victor Duchovni IT Security, Morgan Stanley - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Reliance on Microsoft called risk to U.S. security
The report, written by many a crypto list member, is at: http://www.ccianet.org/papers/cyberinsecurity.pdf Will Rodger - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Reliance on Microsoft called risk to U.S. security
On Saturday, Sep 27, 2003, at 15:48 US/Eastern, [EMAIL PROTECTED] wrote: On Sat, 27 Sep 2003, Jeroen C.van Gelderen wrote: I continue to believe that few users would grant an email message access to both the Internet and the Address Book when they are asked those two questions, provided that the user had not been conditioned to clicking YES in order to get any work done at all. You have not met my users! Indeed, but I'm here to learn :) This is really rather naive. Users don't understand pop dialogues, they raise their stress level, always clicking yes makes the problem go away. True. But don't you think that this may be in part because the popup dialogues are shown way too often in the course of normal use? And because they ask questions that cannot be understood by Real Users? Is it naive to assume that Real Users are intelligent but that an ill-designed security architecture has *conditioned* them to always click YES, as you say because that is the only way for them to get any work done at all? I have to imagine starting with a clean slate, with unconditioned users. Now imagine that the Alice, a Real User, can usually do a full day's worth of work (Excel, Word, Browsing, Email) without seeing a security popup asking some weird question. Imagine this is the status quo. In this scenario, a security popup is cause for concern. After all, normal use doesn't result in popups so this is a clear indication that something is wrong. Why would she click YES? Now additionally imagine that security popups ask Alice an intelligible question. Not FooBar is trying TCP to port 1223, that okay with you? but rather something like This website wants access to ALL YOUR PERSONAL FILES, that okay with you? Or: This email wants to access the Internet and your Address Book, that okay with you? Because I'm an optimist I believe that Alice will read the dialog and err on the side of caution. Maybe that isn't realistic. So we teach Alice to always click NO. We can do so because unlike today, Alice's NO will not interfere with her ability to get work done. Also security is not closed under composition, two individually secure components can combine to produce an insecure system. I think that no such secure *non-trivial* least privilege system exists for a graphical general purpose computer either in theory, or in practice. Are you familiar with the KeyKOS and EROS operating systems and/or Stiegler's CapDesk, a secure desktop in Java? They are all based on the Principle Of Least Privilege (trough capabilities) and they manage to preserve security in the face of composition. Do you consider those systems to be trivial, or broken? What is the reason these systems cannot exist in theory or practice? What fraction of real users will be able to use these systems? Will users really understand the composition properties of security policies? I agree that such composition must be intuitive or we cannot expect it to work. I think that CapDesk is a nice publicly available prototype of a workable capability desktop. It would be very interesting to see your assessment on whether a CapDesk approach would be workable for your users. And if it isn't, why not. I hope you can lend your experience. Cheers, -J - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Reliance on Microsoft called risk to U.S. security
also sprach Ian Grigg [EMAIL PROTECTED] [2003.09.25.2253 +0200]: I wouldn't put all of the blame on Microsoft, Schneier said, the problem is the monoculture. On the face of it, this is being too kind and not striking at the core of Microsoft's insecure OS. For example, viruses are almost totally a Microsoft game, simply because most other systems aren't that vulnerable. Yes and no. First, I think that viruses will surface were e.g. Linux to take top position, albeit they may have to employ totally new paradigms to subvert the more advanced security architecture of UNIX. But I believe Schneier is right for the following reason: Microsoft is a monopolist who, despite enjoying bad press for the past four years, is managing to keep its sales going up each quarter. If you are in business, what do you care for? The steep sales curve, or the quality of your product? As long as Microsoft has the monopoly on the desktop, as long as new computers come with Windows per default, and as long as people stop complaining and actually take action against the crap that Redmond ships by switching to other systems in bulk, Microsoft has no reason to invest any money in a code rework. So, in the market for server platform OSs, is there any view as to which are more secure, and whether that insecurity can be traced to the OS? The defacement archive[1] has some statistics. But don't let yourself be fooled as one should not forget that while Windows usually comes with one web-, one mail-, one DNS server, there are like 27 and up in each category for UNIX. So theoretically, when comparing those categories, you need to include a factor of 27. 1. http://defaced.alldas.org/ -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED] invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver! women love us for our defects. if we have enough of them, they will forgive us everything, even our gigantic intellects. -- oscar wilde pgp0.pgp Description: PGP signature
Re: Reliance on Microsoft called risk to U.S. security
On Thu, 25 Sep 2003, Ian Grigg wrote: On the face of it, this is being too kind and not striking at the core of Microsoft's insecure OS. For example, viruses are almost totally a Microsoft game, simply because most other systems aren't that vulnerable. While part of the security problems in Windows are Microsoft specific, in my view a large part is inherited from earlier graphiscal desktop designs, and is almost universal in this space. Specifically, when a user clicks (or double-clicks) on an icon there is not a clear distinction between Run and View. Instead we have the polymorphic Open. If files always opened in a safe viewer, (e.g. clicking on a .pl file fired up an editor, not the ActiveState Perl interpreter) a good part of the security problem with Graphical desktops, Microsoft's, Apple's, RedHat's, ... would be solved. The bizarre advice we give users to not open message attachments would be largely unnecessary (one also needs to close the the macro invocation problem, but this is not insurmountable). It is my contention that so long as activating an icon does not distinguish between Run and View all Graphical Shells will be insecure. -- Victor Duchovni IT Security, Morgan Stanley - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Reliance on Microsoft called risk to U.S. security
At 6:47 AM -0700 9/26/03, [EMAIL PROTECTED] wrote: While part of the security problems in Windows are Microsoft specific, in my view a large part is inherited from earlier graphiscal desktop designs, and is almost universal in this space. Specifically, when a user clicks (or double-clicks) on an icon there is not a clear distinction between Run and View. Instead we have the polymorphic Open. If files always opened in a safe viewer, (e.g. clicking on a .pl file fired up an editor, not the ActiveState Perl interpreter) a good part of the security problem with Graphical desktops, Microsoft's, Apple's, RedHat's, ... would be solved. The bizarre advice we give users to not open message attachments would be largely unnecessary (one also needs to close the the macro invocation problem, but this is not insurmountable). It is my contention that so long as activating an icon does not distinguish between Run and View all Graphical Shells will be insecure. The real problem is that the viewer software, whether it is an editor, PDF viewer, or a computer language interpreter, runs with ALL the user's privileges. If we ran these programs with a minimum of privilege, most of the problems would just go away. See: http://www.combex.com/tech/edesk.html http://www.combex.com/papers/darpa-review/index.html http://www.combex.com/papers/darpa-report/index.html Cheers - Bill - Bill Frantz| There's nothing so clear as | Periwinkle (408)356-8506 | vague idea you haven't written | 16345 Englewood Ave www.pwpconsult.com | down yet. -- Dean Tribble | Los Gatos, CA 95032 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Reliance on Microsoft called risk to U.S. security
http://channels.netscape.com/ns/news/story.jsp?id=200309241951000228064dt=20030924195100w=RTRcoview= Reliance on Microsoft called risk to U.S. security SEATTLE, Sept 24 (Reuters) - Computer security experts issued a joint report on Wednesday saying that the ubiquitous reach of Microsoft Corp.'s software on desktops worldwide has made computer networks a national security risk susceptible to massive, cascading failures. The report, unveiled at the Computer Communications Industry Association's meeting of industry leaders and government officials in Washington, D.C., saying that Microsoft is now the number one target for malicious computer virus writers. The report's authors told CCIA -- which is funded by Microsoft rivals -- that the software's complexity has made it particularly vulnerable to attacks. So far this year, two major viruses emerged that took advantage of flaws in Microsoft software. Slammer, which targeted computers running Microsoft's server-based software for databases, slowed down Internet traffic across the globe and shut down flight reservation systems and cash machines in the United States. The Blaster worm burrowed through hundreds of thousands of computers, destroying data and launching attacks on other computers. The nature of the platform that dominates every desktop everywhere is such that its dominance, coupled with its insecurity, cannot be ignored and is a matter of corporate and national policy, said Dan Geer, a security consultant and chief technology officer of @Stake, a computer security company. Geer, along with other well-known computer security experts Rebecca Bace, Peter Gutmann, Perry Metzger, Charles Pfleeger, John Quarterman, and Bruce Schneier, said they issued their report to raise awareness of the risk to national security by using a single, wide-spread software system. The report's authors said the report was a reflection of their own views and not necessarily those of the CCIA, an industry trade group of Microsoft's competitors that has a long history of suing the world's largest software maker. But in response to the report, Americans for Technology Leadership, an industry trade group backed by Microsoft and other companies and organizations, called the report an attempt by the CCIA to exploit the serious issue of cyber-security. Cyber-security is an industry-wide problem that will not be solved by malicious finger pointing and political attacks, Jim Prendergast, executive director of Americans for Technology Leadership, said in a statement. IS MONOPOLY THE PROBLEM? Microsoft, which launched its Trustworthy Computing initiative in early 2002 to make its software more secure and reliable, said it is continuing to work with its customers and the government to make its software as secure, private and reliable as possible. Microsoft considers security for all of our customers -- from government networks to individual PC users -- to be our top priority, said Microsoft spokeswoman Ginny Terzano. The widespread use of Microsoft products around the world means we are constantly working to be responsive when vulnerabilities occur. But the security experts said the issue of computer security had more to do with the ubiquity of Microsoft's software than any flaws in the software. The best solution, the report's authors argued, is to adopt a mix of different computer systems that will reduce the risk of a single security incident crippling a company or a government agency. Having more than one operating system running inside your enterprise would be a substantial improvement, said Geer. Bruce Schneier, a co-author of the report and chief technology officer of network monitoring firm Counterpane Security, noted a recent initiative by Japan, Korea and China to develop an alternative operating system to Microsoft's Windows to enhance security. I wouldn't put all of the blame on Microsoft, Schneier said, the problem is the monoculture. -- - R. A. Hettinga mailto: [EMAIL PROTECTED] The Internet Bearer Underwriting Corporation http://www.ibuc.com/ 44 Farquhar Street, Boston, MA 02131 USA ... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience. -- Edward Gibbon, 'Decline and Fall of the Roman Empire' - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Reliance on Microsoft called risk to U.S. security
R. A. Hettinga wrote: http://channels.netscape.com/ns/news/story.jsp?id=200309241951000228064dt=20030924195100w=RTRcoview= Reliance on Microsoft called risk to U.S. security But the security experts said the issue of computer security had more to do with the ubiquity of Microsoft's software than any flaws in the software. I wouldn't put all of the blame on Microsoft, Schneier said, the problem is the monoculture. On the face of it, this is being too kind and not striking at the core of Microsoft's insecure OS. For example, viruses are almost totally a Microsoft game, simply because most other systems aren't that vulnerable. But, it is also possible to secure M$ OSs, so maybe there is some merit to not putting all the blame on Microsoft. Either way, it can be tested. There is one market where M$ has not dominated, and that is the server platform. I haven't looked for a while, but last I looked, the #1,2,3 players were Linux, Microsoft, FreeBSD, and only a percentage point or two separated them. (I'm unsure of the relative orders. And this relates to testable web server platforms, rather than all servers.) So, in the market for server platform OSs, is there any view as to which are more secure, and whether that insecurity can be traced to the OS? Or external factors such as a culture of laziness in installing patches, or derivative vulnerability from being part of the monoculture? (I raise this as a research question, not expecting any answers!) iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
