At 18:03 08/06/2003 -0400, Tim Dierks wrote: <skip>

- Get browser makers to design better ways to communicate to users that UI elements can be trusted. For example, a proposal I saw recently which would have the OS decorate the borders of "trusted" windows with facts or images that an attacker wouldn't be able to predict: the name of your dog, or whatever. (Sorry, can't locate a link right now, but I'd appreciate one.)

Here are two... Yuan, Ye and Smith, Trusted Path for Browsers, 11th Usenix security symp, 2002. Ka Ping Yee, User Interface Design for Secure System, ICICS, LNCS 2513, 2002. This issue is also covered somewhat by my article in CACM (May 2002). Best, Amir Herzberg http://amir.herzberg.name

- Combine the two to allow sites to provide a user-trustable UI to enter a password which cannot be sucked down. - Evangelize to users that this is better and that they should be suspicious of any situation where they used such interface once, but now it's gone.

I agree that the overall architecture is broken; the problem is that it's broken in more ways than can just be fixed with any change to TLS/SSL or HTTPS.

- Tim

--------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

-------------------------------------------------------------------------------------------------------------------------------- Amir Herzberg http://amir.herzberg.name --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

in a world where there are repeated human mistakes/failures .... at some point it is recognized that people aren't perfect and the design is changed to accommodate peoples foibles. in some respects that is what helmets, seat belts, and air bags have been about.

The problem is here, we are blaming the protective device for not being able to protect against the deliberate use of an attack that bypasses, not challenges it - by exploiting the gullibility or tendency to take the path of least resistance of the user. The real weakness in HTTPS is the tendency of certificates signed by Big Name CAs to be automagically trusted - even if you have never visited that site before. yes, you can fix this almost immediately by untrusting the root certificate - but then you have to manually verify each and every site at least once, and possibly every time if you don't mark the cert as "trusted" for future reference. To blame HTTPS for an attack where the user fills in a web form received via html-rendering email (no https involved at all) is more than a little unfair though.

in the past systems have designed long, complicated passwords that are hard to remember and must be changed every month. that almost worked when a person had to deal with a single shared-secret. when it became a fact of life that a person might have tens of such different interfaces it became impossible. It wasn't the fault of any specific institution, it was a failure of humans being able to deal with large numbers of extremely complex, frequently changing passwords. Because of known human foibles, it might be a good idea to start shifting from an infrastructure with large numbers of shared-secrets to a non-shared-secret paradigm.

I am not aware of one (not that that means much, given I am a novice in this field) Even PKI relies on something close to a shared secret - a *trustworthy* copy of the public key, matching a secret copy of the private key. In x509, this trustworthyness is established by an Ultimately Trusted CA; in pgp, by the Web Of Trust, in a chain leading back to your own key; in SSH, by your placing of the public key into your home dir manually (using some other form of authentication to presumably gain access) in each of these cases, the private key will almost invariably be protected by a passphrase; at best, you can have a single passphrase (or even single private key) to cover all bases.. but that just makes that secret all the more valuable.

at a recent cybersecurity conference, somebody made the statement that (of the current outsider, internet exploits, approximately 1/3rd are buffer overflows, 1/3rd are network traffic containing virus that infects a machine because of automatic scripting, and 1/3 are social engineering (convince somebody to divulge information). As far as I know, evesdropping on network traffic doesn't even show as a blip on the radar screen. That is pretty much because defence occupies the position of the interior - attackers will almost invariably attack weak points, not strong ones. It is easy to log and calculate how many attacks happen on weak points, but impossible to calculate how many attacks *would* have happened had the system not been in place to protect against such attacks, so the attackers moved onto easier targets. It makes little sense to try and break one https connection (even at 40 bit) if by breaking into the server you get that information, hundreds of others (until discovered) and possibly thousands of others inadvisedly stored unprotected in a database.

<snip>

The types of social engineering attacks then become convincing people to insert their hardware token and do really questionable things or mailing somebody their existing hardware token along with the valid pin (possibly as part of an exchange for replacement). The cost/benefit ratio does start to change since there is now much more work on the crooks part for the same or less gain. One could also claim that such activities are just part of child-proofing the environment (even for adults). On the other hand, it could be taken as analogous to designing systems to handle observed failure modes (even when the failures are human and not hardware or software). Misc. identify theft and credit card fraud reference:

Which again matches well to the Nigerian analogy. Everyone *knows* that handing over your bank details is a Bad Thing - yet they still do it. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

-- On 8 Jun 2003 at 20:00, Anne & Lynn Wheeler wrote:

that is why we coined the term merchant "comfort" certificates some time ago. my wife and I having done early work for payment gateway with small client/server startup in menlo park ... that had this thing called SSL/HTTPS ... and then having to perform due diligence on the major issuers of certificates .... we recognized 1) vulnerabilities in the certificate process and 2) information hiding of transaction in flight only addressed a very small portion of the vulnerabilities and exploits.

https is like a strong fortress wall that only goes half way around the fortress. The most expensive and inconvenient part of https, getting certificates from verisign, is fairly useless. The useful part of https is that it has stopped password sniffing from networks, but the PKI part, where the server, but not the client, is supposedly authenticated, does not do much good. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG 9ZQw+0/xh1y28CkGulSQSVxewfy71qzXGHI8KJbN 4osBv1veq07jaMVh2zVetZVKqIRfQjiwJaKu99GqM

On 06/11/2003 10:56 AM, Sunder wrote:

www.foo.com www.bar.com www.baz.com can't all live on the same IP and have individual ssl certs for https. :( This is because the cert is exchanged before the http 1.1 layer can say "I want www.bar.com"

So you need to waste IP's for this. Since the browser standards are already in place, it's unlikely to be to find a workaround.

A reasonable workaround might be something like: http://www.ietf.org/rfc/rfc3056.txt ... to allow isolated IPv6 domains or hosts, attached to an IPv4 network which has no native IPv6 support, to communicate with other such IPv6 domains or hosts with minimal manual configuration, before they can obtain natuve IPv6 connectivity. It incidentally provides an interim globally unique IPv6 address prefix to any site with at least one globally unique IPv4 address, even if combined with an IPv4 Network Address Translator (NAT). --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

-- On 9 Jun 2003 at 2:09, Dave Howe wrote:

The problem is here, we are blaming the protective device for not being able to protect against the deliberate use of an attack that bypasses, not challenges it - by exploiting the gullibility or tendency to take the path of least resistance of the user. The real weakness in HTTPS is the tendency of certificates signed by Big Name CAs to be automagically trusted - even if you have never visited that site before. yes, you can fix this almost immediately by untrusting the root certificate - but then you have to manually verify each and every site at least once, and possibly every time if you don't mark the cert as "trusted" for future reference. To blame HTTPS for an attack where the user fills in a web form received via html-rendering email (no https involved at all) is more than a little unfair though.

How many attacks have there been based on automatic trust of verisign's feckless ID checking? Not many, possibly none. That is not the weak point, not the point where the attacks occur. If the browser was set to accept self signed certificates by default, it would make little difference to security. A wide variety of ways of getting big name certificates that one should not have, have been discovered. Attackers never showed much interest. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG uJuAm4Xwyo4xTn0ozjBmW2ZqpI8Z3ru25WDmB7iw 43PXj2QDpBfcahqs2aOleapJYsqtA6S36+hOdVkpR --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

At 06:12 PM 6/8/2003 -0600, Anne & Lynn Wheeler wrote:

at a recent cybersecurity conference, somebody made the statement that (of the current outsider, internet exploits, approximately 1/3rd are buffer overflows, 1/3rd are network traffic containing virus that infects a machine because of automatic scripting, and 1/3 are social engineering (convince somebody to divulge information). As far as I know, evesdropping on network traffic doesn't even show as a blip on the radar screen.

virus attempting to harvest ("shared-secret", single-factor) passwords at financial institutions http//www.smh.com.au/articles/2003/06/10/1055010959747.html and somewhat related: http://www.garlic.com/~lynn/aepay11.htm#53 authentication white paper -- Anne & Lynn Wheeler http://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

The problem with these stop crackers and hackers by law is that it allows software developers to get away with leaving huge gaping security holes unfixed. Anecodatal evidence: The classic well known Robin Hood and Friar Tuck "hack". These days, the bug wouldn't get fixed and the guys reporting it would wind up in jail because they "convinced" the OS authors to fix the bug. IMHO, not the right way to go at all. from http://ftp.arl.mil/ftp/unix-wizards/V16%23017 scroll down a bit more than half way down the page (also available from most other GNU sources) Back in the mid-1970s, several of the system support staff at Motorola discovered a relatively simple way to crack system security on the Xerox CP-V timesharing system. Through a simple programming strategy, it was possible for a user program to trick the system into running a portion of the program in `master mode' (supervisor state), in which memory protection does not apply. The program could then poke a large value into its `privilege level' byte (normally write-protected) and could then proceed to bypass all levels of security within the file-management system, patch the system monitor, and do numerous other interesting things. In short, the barn door was wide open. Motorola quite properly reported this problem to Xerox via an official `level 1 SIDR' (a bug report with an intended urgency of `needs to be fixed yesterday'). Because the text of each SIDR was entered into a database that could be viewed by quite a number of people, Motorola followed the approved procedure: they simply reported the problem as `Security SIDR', and attached all of the necessary documentation, ways-to-reproduce, etc. The CP-V people at Xerox sat on their thumbs; they either didn't realize the severity of the problem, or didn't assign the necessary operating-system-staff resources to develop and distribute an official patch. Months passed. The Motorola guys pestered their Xerox field-support rep, to no avail. Finally they decided to take direct action, to demonstrate to Xerox management just how easily the system could be cracked and just how thoroughly the security safeguards could be subverted. They dug around in the operating-system listings and devised a thoroughly devilish set of patches. These patches were then incorporated into a pair of programs called `Robin Hood' and `Friar Tuck'. Robin Hood and Friar Tuck were designed to run as `ghost jobs' (daemons, in UNIX terminology); they would use the existing loophole to subvert system security, install the necessary patches, and then keep an eye on one another's statuses in order to keep the system operator (in effect, the superuser) from aborting them. One fine day, the system operator on the main CP-V software development system in El Segundo was surprised by a number of unusual phenomena. These included the following: * Tape drives would rewind and dismount their tapes in the middle of a job. * Disk drives would seek back and forth so rapidly that they would attempt to walk across the floor (see {walking drives}). * The card-punch output device would occasionally start up of itself and punch a {lace card}. These would usually jam in the punch. * The console would print snide and insulting messages from Robin Hood to Friar Tuck, or vice versa. * The Xerox card reader had two output stackers; it could be instructed to stack into A, stack into B, or stack into A (unless a card was unreadable, in which case the bad card was placed into stacker B). One of the patches installed by the ghosts added some code to the card-reader driver... after reading a card, it would flip over to the opposite stacker. As a result, card decks would divide themselves in half when they were read, leaving the operator to recollate them manually. Naturally, the operator called in the operating-system developers. They found the bandit ghost jobs running, and X'ed them... and were once again surprised. When Robin Hood was X'ed, the following sequence of events took place: !X id1 id1: Friar Tuck... I am under attack! Pray save me! id1: Off (aborted) id2: Fear not, friend Robin! I shall rout the Sheriff of Nottingham's men! id1: Thank you, my good fellow! Each ghost-job would detect the fact that the other had been killed, and would start a new copy of the recently slain program within a few milliseconds. The only way to kill both ghosts was to kill them simultaneously (very difficult) or to deliberately crash the system. Finally, the system programmers did the latter --- only to find that the bandits appeared once again when the system rebooted! It turned out that these two programs had patched the boot-time OS image (the kernel file, in UNIX terms) and had added themselves to the list of programs that were to be started at boot time. The Robin Hood and Friar Tuck ghosts were finally eradicated when the system staff rebooted the system from a clean boot-tape and reinstalled the monitor. Not long thereafter, Xerox released a patch for this problem. It is alleged that Xerox filed a complaint with Motorola's management about the merry-prankster actions of the two employees in question. It is not recorded that any serious disciplinary action was taken against either of them. ----------------------Kaos-Keraunos-Kybernetos--------------------------- + ^ + :25Kliters anthrax, 38K liters botulinum toxin, 500 tons of /|\ \|/ :sarin, mustard and VX gas, mobile bio-weapons labs, nukular /\|/\ <--*-->:weapons.. Reasons for war on Iraq - GWB 2003-01-28 speech. \/|\/ /|\ :Found to date: 0. Cost of war: $800,000,000,000 USD. \|/ + v + : The look on Sadam's face - priceless! --------_sunder_@_sunder_._net_------- http://www.sunder.net ------------ On Tue, 10 Jun 2003, Bill Frantz wrote:

At 5:12 PM -0700 6/8/03, Anne & Lynn Wheeler wrote:

...

somebody (else) commented (in the thread) that anybody that currently (still) writes code resulting in buffer overflow exploit maybe should be thrown in jail.

A nice essay, partially on the need to include technological protections against human error, included the above paragraph.

IMHO, the problem is that the C language is just too error prone to be used for most software. In "Thirty Years Later: Lessons from the Multics Security Evaluation", Paul A. Karger and Roger R. Schell <www.acsac.org/2002/papers/classic-multics.pdf> credit the use of PL/I for the lack of buffer overruns in Multics. However, in the Unix/Linux/PC/Mac world, a successor language has not yet appeared.