Re: Let's be paranoid about CSS (cascaded style sheet) as an application data integrity attack vector!
On Tue, Sep 09, 2008 at 01:52:30PM -0500, Thierry Moreau wrote: > Here is a simple exploit which alters the ietf.org main page. Insert the > following four lines > > [...] > > to the file /usr/lib/firefox/res/html.css > > [...] > > OK, this requires root access because the Linux community is generally > security-conscious. But you should see the general idea: paranoia leads me > to think of an adversary who would threatens application integrity (such as > the above) without leaving much trace of computer system penetration. > > [...] > > Does anybody have any tip about how to mitigate this vulnerability, with > minimal assumptions about the client web browser? As the service provider you have little choice but to assume local security on the client side IF you want to allow clients that you don't control (and you don't really have a choice about _that_; most SPs don't anyways). I don't see how to mitigate all possible attacks you can imagine that involve a compromised client. > The habit of storing css style information in various style sheets files > separate from the HTML contents is worrysome as each stylesheet retrieval > operation is a potential attack vector. You could say the same thing about AJAX, ... This train left the station long ago, and I was on it then along with everyone else. Nico -- - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: once more, with feeling.
Peter Gutmann wrote: Unfortunately I think the only way it (and a pile of other things as well) may get stamped out is through a multi-pronged approach that includes legislation, and specifically properly thought-out requirements rather than big-business- bought legislation like UCITA/UCC or easily-circumvented recommendations like the FFIEC ones (the banks quickly discovered that by redefining "two-factor auth" to mean "twice as much one-factor auth" they could meet the requirements without having to do anything to improve security). The average cryptographic expert finds it tricky to set up something that is actually secure. The average bureaucrat could not run a pie stand. Legislation and so forth requires wise and good legislators and administrators, which is unlikely. Visualize Obama, McCain, or Sarah Palin setting up your network security. Then realize that whoever they appoint as Czar in charge of network security is likely to be less competent than they are. I'm saying that under the influence of "Zero Day Threat" by Byron Acohido and Jon Swartz, which looks at some of the financial and credit-reporting industry practices that make identity fraud possible. If you haven't read this already, go and get it now, apart from the annoyingly frequent context- switching between threads (one every few pages instead of the more usual one per chapter) it's a very scary read. Given what it reveals about how the US financial/credit reporting industry works it should really be subtitled "We're all going to die", since there's no obvious handbrake mechanism present in the system to slow down identity theft - the rate-limiting step is the fact that the crooks simply can't use all the stolen identities they have, not any security measures that may be present. If you don't believe me, visit any of the hits from the following search: http://www.google.com/search?q=fullz+dumps (that's the easiest way to demo the problem to the masses without requiring people to learn to read cyrillic first :-). Yup, we're all going to die. So that there becomes a directly attributable financial impact to the sites that deploy in that way. The "financial impact" point is the key word, at the moment it's cheaper and easier for the banks/credit reporting companies to be non-compliant/insecure than it is for them to be secure. I'm not sure that the browser is the most effective way to hit them over this though. Discuss :-). Peter. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Bletchley Park restoration
[Moderator's note: I posted on this earlier, but I really do want to see Bletchley Park maintained... :) --Perry] IBM and PGP have donated $100,000 to help restore and maintain Bletchley Park as a museum. This money is intended to get others involved - millions more will be needed. Details: http://news.bbc.co.uk/2/hi/technology/7604762.stm -- Jerry - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: More US bank silliness
* Peter Gutmann: > On a semi-related topic, it'd be interesting to get some discussion about FF3 > removing the FF2 SSL indicators of the padlock and (more visibly) the > background colour-change for the URL bar when SSL is active and replacing it > with a spoof-friendly indicator that's part of the favicon, i.e. part of the > attacker-controlled content. To keep this in perspective, note that you could disable the location bar altogether in FF2 (and that default changed in FF3), so the FF3 approach is actually an improvement. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Let's be paranoid about CSS (cascaded style sheet) as an application data integrity attack vector!
Dear security experts:
Suppose I want to use the HTML syntax and a plain web browser as a user
interface for a secure application. By "secure", I mean, among other
things, that the application service provider is confident that the user
sees the HTML contents without integrity vulnerabilities. Of course,
https is the only allowed protocol for reaching this web page, and the
only protocol present in any link from this page to a next one.
I am now concerned about the default and implicit style sheets that the
web browser uses for HTML content rendering.
Here is a simple exploit which alters the ietf.org main page. Insert the
following four lines
a[title="IETF Secretariat"]:before
{content: "Don't trust the "}
a[title="IETF Secretariat"]:after
{content: " for anything security-critical."}
to the file /usr/lib/firefox/res/html.css
then restart the Mozilla Firefox and bingo, the itef.org main page is
subrepticiously changed. I.e. the link to "IETF Secretariat" is canged
to "Don't trust the IETF Secretariat for anything security-critical."
OK, this requires root access because the Linux community is generally
security-conscious. But you should see the general idea: paranoia leads
me to think of an adversary who would threatens application integrity
(such as the above) without leaving much trace of computer system
penetration.
This attack vector is trivial based on the HTML markup language
philosophy - the above "exploit" merely alters default settings in a
parameter specifications language (css) having a fine grained
expressivity potential. CSS is about what the user sees when HTML
contents is displayed on a media (typically a web browser.
Does anybody have any tip about how to mitigate this vulnerability, with
minimal assumptions about the client web browser?
The basic idea would be to "patch" any default setting (that could alter
the user display ...) in the CSS specifications with explicit parameter
setting associated with the HTML contents. In the above case, the IETF
can protect itself with the following HTML markup text near the
beginning of the file:
:before{content:""}:after{content:""}
The habit of storing css style information in various style sheets files
separate from the HTML contents is worrysome as each stylesheet
retrieval operation is a potential attack vector.
Thanks in advance. More specifically, with the hope that paranoia can
sometimes be a productive state of mind, I remain paranoid-ly grateful
for your answers.
--
- Thierry Moreau
CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada H2M 2A1
Tel.: (514)385-5691
Fax: (514)385-5900
web site: http://www.connotech.com
e-mail: [EMAIL PROTECTED]
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: once more, with feeling.
Peter Gutmann writes, in part: -+ | ... - the rate-limiting step is the fact that | the crooks simply can't use all the stolen identities | they have, not any security measures that may be present. | ... To my knowledge, you are correct. It seems that the price of stolen credentials (on the black market) is falling, which, as with the street price of heroin, would tend to indicate that the opposition is winning. I have a slide for this somewhere (not on this machine) and will dig it up if needed, but the disparity between actual crime and a naive estimate of the opportunity for crime seems to be widening. If correct, then such a disparity would either indicate that our countermeasures are winning -or- the predators are leaving prey on the field. I'm sadly of the opinion that it is the latter. In their Internet Security Threat Report, Symantec used to publish the number of bots detected. The last one of those I have at hand showed a leveling out of the number found de novo per unit interval (per month). Again, this permits two interpretations; on the one hand, we are winning in that we are preventing the problem from worsening while on the other hand it can be read to mean that as fast as we remove bots from hosts that other hosts are botted and, as such, the supply of bots being stable implies that it is easy enough to replace them that the lost of an individual host does not slow down our opposition. What does (in the Symantec graphs) vary is the variance of in-and-out-flow, but not the fraction that are botted. This would tend to strengthen the argument that any periodic sweep of bots off networks is compensated for relatively quickly. In public health, widely varying incidence (new infection rate) but stable prevalence (infected fraction) tends to indicate a high degree of infectability and not a particularly effective immune response. We see this in a way in the AIDS data -- every advance in treatability seems to be followed by increases in risky behavior while prevalence remains to a degree stable. This idea of replacement of cured machines by infected machines seems corroborated in a different way as well. The opposition seems to have lately decided that the advantages of stealth outway the advantages of persistence, which is to say that in-core-only infection is now the preferred mechanism and not writing to disk so as to preserve infected status through a reboot cycle. If this is correct, then it signals that the opposition can replace machines lost through reboot easily enough that the availability of penetrated machines can be better enhanced through making infections harder to find (latent, in medical parlance) than through making a once penetrated machine stay penetrated as to do the latter you have to expose yourself to periodic clean-up of that which is persistent (on disk). For anyone looking ahead, the interaction between this phenomenon (if it is indeed a phenomenon) and the growing role of virtual machines should be of intense interest. Inferentially yours, --dan - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
US firms donate $100,000 to help save Bletchley Park
Excerpt: The Americans have joined the campaign to save Bletchley Park, the home of code breaking during the Second World War, as well as of Britain's computing heritage, with IBM and computer security specialist PGP already pledging 57,000 pounds (about $100,000) to secure the facility's future. The donation will help restore exhibits at the National Museum of Computing in Bletchley Park[...] http://www.eetimes.com/rss/showArticle.jhtml?articleID=210600420 -- Perry E. Metzger[EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: once more, with feeling.
Darren J Moffat <[EMAIL PROTECTED]> writes: >I believe the only way both of these highly dubious deployment practices will >be stamped out is when the browsers stop allowing users to see such web pages. Unfortunately I think the only way it (and a pile of other things as well) may get stamped out is through a multi-pronged approach that includes legislation, and specifically properly thought-out requirements rather than big-business- bought legislation like UCITA/UCC or easily-circumvented recommendations like the FFIEC ones (the banks quickly discovered that by redefining "two-factor auth" to mean "twice as much one-factor auth" they could meet the requirements without having to do anything to improve security). I'm saying that under the influence of "Zero Day Threat" by Byron Acohido and Jon Swartz, which looks at some of the financial and credit-reporting industry practices that make identity fraud possible. If you haven't read this already, go and get it now, apart from the annoyingly frequent context- switching between threads (one every few pages instead of the more usual one per chapter) it's a very scary read. Given what it reveals about how the US financial/credit reporting industry works it should really be subtitled "We're all going to die", since there's no obvious handbrake mechanism present in the system to slow down identity theft - the rate-limiting step is the fact that the crooks simply can't use all the stolen identities they have, not any security measures that may be present. If you don't believe me, visit any of the hits from the following search: http://www.google.com/search?q=fullz+dumps (that's the easiest way to demo the problem to the masses without requiring people to learn to read cyrillic first :-). Yup, we're all going to die. >So that there becomes a directly attributable financial impact to the sites >that deploy in that way. The "financial impact" point is the key word, at the moment it's cheaper and easier for the banks/credit reporting companies to be non-compliant/insecure than it is for them to be secure. I'm not sure that the browser is the most effective way to hit them over this though. Discuss :-). Peter. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
"usable security" at www.usable.com
www.usable.com has launched a new password management service intended to make it easy to login to participating web sites. However, I don't see any details of the protocols or algorithms. In particular, I don't see any mention of whether or not the system even attempts to prevent people with access to the servers at usable.com from having the ability to impersonate users of the service. --apb (Alan Barrett) - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: More US bank silliness
Sebastian Krahmer <[EMAIL PROTECTED]> writes: >This reminds me the most weird SSL related error message I have ever seen and >which is there since ages: > >https://www.fbi.gov > >Beside that the certificate is wrong :-) That's an artefact of the SSL MITM that Akamai performs for sites that are hosted via their service (and up until Kevin Fu pointed out that this was a problem, any random site you want as well). You usually don't see this though, so it's indicative of a configuration error somewhere... Peter. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Student hacker exposes Carleton U cash, ID card security holes
Student hacker exposes Carleton U cash, ID card security holes http://www.cbc.ca/canada/ottawa/story/2008/09/08/ot-security-080908.html "A Carleton University student has revealed that he stole data containing e-mail passwords, financial data and library account information from 32 students at the university in order to expose security holes in the system. The card's design for both financial and identification purposes and its "inadequate safeguards against information leakage" could lead to identity or financial fraud, said the 20-year-old student of the Ottawa university in a document e-mailed to the victims Sunday evening under the alias Kasper Holmberg." ... There's a few inconsistencies in this story, first claiming that this student is from one university in Ottawa, Ontario, then the other, except that Ottawa University is in Ottawa, Kansas while the University of Ottawa is in Ottawa, Ontario. CBC should have been able to get those mundane details right so who knows about the other details... As usual, the institution involved missed the point... slainte mhath, RGB -- Richard Guy Briggs -- ~\-- ~\ -- \___ o \@ @ Ride yer bike! Ottawa, ON, CANADA -- Lo_>__M__\\/\%__\\/\% Vote! -- _GTVS6#790__(*)__(*)(*)(*)_ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: once more, with feeling.
On Mon, 8 Sep 2008, Adam Shostack wrote: What makes now the perfect time to address an issue which has been present for quite soem time? I'd turn that question around, and ask what makes now such a bad time to address an issue that's been present (and not addressed) for quite some time... ? Surely the recent DNS fiasco was enough of an illustration of the merits of not worrying about something that's been a well known issue for ages... cheers! == "A cat spends her life conflicted between a deep, passionate and profound desire for fish and an equally deep, passionate and profound desire to avoid getting wet. This is the defining metaphor of my life right now." - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
