Slashdot Mirror
Unicode Encoding Flaw Widespread
LordNikon writes "According to this CERT advisory: 'Full-width and half-width encoding is a technique for encoding Unicode characters. Various HTTP content scanning systems fail to properly scan full-width/half-width Unicode encoded HTTP traffic. By sending specially-crafted HTTP traffic to a vulnerable content scanning system, an attacker may be able to bypass that content scanning system.' A proof of concept affecting IIS is already being posted to security mailing lists. Cisco IPS and other IDS products are also affected." The CERT advisory lists 93 systems, with 6 reported as vulnerable (including 3com, Cisco, and Snort), 5 known not vulnerable (including Apple and HP), and the rest unknown.
This appears to be limited to content scanning, and isn't really a vulnerability in itself. Relying on content scanning to prevent an exploit to reach an exploitable system is a pretty bad idea, much better to fix the system than the extra layer of defense on the outside.
Content scanning is mostly useful against filtering known exploits, and is hardly meant to be your primary defense. Being able to bypass this scanning won't buy you much. If the content scanner is aware of an exploit it scans for, chances are so are the systems being targeted and are patched to protect against it.
I.O.U One Sig.
Quick! Claim the $16,000! http://it.slashdot.org/article.pl?sid=07/05/18/189 208
"It's very hard to exploit [those listed applications]," Aitel said. "IIS 6 hasn't had a public remotely exploitable bug in it. Ever."
Doh!
I work incident response in a large web company (hence anonymous posting, natch) and currently we're treating this as "interesting, but case not proven". We test our web apps filter all input so I'm adding double-width unicode to our security regression test cases; however I'm happy to let the FD posters lab it out between them in the short term. These alleged IIS exploits don't work for us - which is not to say that we don't have some system, somewhere, for which this is an issue. At the end of the day it's just a clear restatement of something that's obvious to anyone - you need to filter input carefully, and you need to be aware of issues around alternative encodings. But it's not a "BRB" (big-red-button, ie emergency stop and all hands to the pumps to fix a vulnerability) issue for us - yet. The last time we had one of those, it was the Microsoft DNS server remote root... because most of our internal domain controllers were also running DNS servers.
According to the advisory, Apple products do not provide HTTP content filtering and are therefore not vulnerable. This will do nothing to help someone build a functioning protection system.
$-$
They've been trying to sell this kind of kit to us for years.
Quack, quack.
What did Apple and HP get right?
Obsolete, obscure, open source, in house?
Domestic spying is now "Benign Information Gathering"
Yeah. Actually, 7 or 8 bits per character really seems excessive to me, and opens the door to additional attack vectors. Surely if people can't take the time to learn to communicate in 1 bit they should not be allowed to use the internet.
will someone please explain to a non security guy why this list is so empty. it seems to me that this should be easy to test for in every IDS type software. I could see more exotic equipment like alcatel being untested yet but it seems there should be enough accessibility of d-link and fedora for example that they should be tested by now. I'd personally test them myself when I got home from work if I knew enough to be able to attempt the exploit.
thats right, I rarely use capitals. deal with it. but don't mistake my laziness for stupidity
I'm wondering if the great firewalls (Cisco product?) are also vulnerable to this. At least it'll force them to do longer string matching.
That Unicode is a very bad idea in all semantics carrying containers is nothing new. In fact one of the counterarguments to Unicode ist that it is a nightmare to secure. Filter evasion was expected to be a typical security concern. We will see more of this and all only because some people want features without ever reflecting on what problems they might cause.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
0 you then!
To think that even English fits in 7-bit ASCII is naïve.
Would some of the things that led to computers - morse code, telegraphy etc have been feasible using, say, Chinese in its normal written form? Are computers biased towards English (and other languages using the same or similar alphabets) because they were largely invented by English speakers, or is the language fundamentally more amenable to small, simple encoding?
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
To think that English doesn't fit in 7-bit ASCII is na\"ive.
If you want to represent a language on a computer (and not just numbers) then you need a way to enter and store all the characters that language uses. Obviously the less characters the better. The latin alphabet with all its variations, the cyrillic , hebrew, arabic & korean all lend themselves to this quite easily since they all have a manageable number of letters. Languages such as Chinese and Japanese don't , they don't even use alpabets , they use characters for each object/concept which as you can imagine is a bugger when you need a keyboard of a manageable size not to mention the memory to store each character bitmap (not an issue now , but 40 years ago it would have been a nightmare).
This is only a guess on my part but I suspect computers would have developed completely differently if they'd been developed by a culture that used symbols rather than alphabets.
1) Chinese doesn't have an alphabet.
2) And the number of unique strokes is actually quite small. It's the combinations of strokes that makes it difficult.
Not all ACs are morons, but this one is.
Would some of the things that led to computers - morse code, telegraphy etc have been feasible using, say, Chinese in its normal written form?
Well, they weren't feasible using English in its normal written form... so I'd guess they wouldn't be feasible using Chinese in it's normal written form either.
Offhand I can't think of any human script or language that's fundamentally suitable to telegraphy. Which isn't really all that surprising.
Whence? Hence. Whither? Thither.
4) You are an idiot
5) You are an asshole
It is a vulnerability, in the strict sense.
...
It is a self-inflicted misbehaviour as in common sense.
It is like those silly Cisco content inspectors on port 25, that try to avoid attacks on flimsy MTAs.
It is like someone dying from a jab against measles: the jab protected that person from contracting measles, actually.
It is like those stupid anti-virus programs that are more vulnerable than the daemons they profess to protect.
When the attacker uses a codepage different from the one that you think she ought to use, she can circumvent your content filter. Which ought not be an attack vector, in any case.
As I said: nothing to see, move along
01010100 01101111 ... ah, screw it, you got the point.
The notable difference between Chinese and English (or most other written languages) is that several English characters combine to form syllables, which combine to form words (i.e., we use an alphabet). In Chinese, each character corresponds directly with a word (each character is a logogram). If you're interested you can look up Alphabet on Wikipedia as a starting point, although I must admit I find the article hard to follow even though I know what it should be saying.
The practical result of this is that English is normally encoded as a long sequence of 0-25 values (a-z), whereas Chinese would be encoded as a shorter sequence of 0-~100,000 values (Wikipedia reports Chinese dictionaries with 85,000 characters). Naturally, there would be fewer Chinese characters required for a message as each character corresponds to an entire word.
I guess that since morse code is rather like binary and English letters can be encoded using 5 bits, Chinese morse codes would need to be... about 20 bits long? It's late at night, brain not work so good. It seems to me that morse codes using 20 dots/dashes would be extremely difficult to learn; but on the other hand it shouldn't be any more difficult than learning Chinese characters in the first place.
I wouldn't be surprised if English morse codes were more robust against poor data, siny Englxsh is stvll reahible even if sew2eral cheracter; are wrong.
Disclaimer: I don't know anything about the subject, I'm talking out of my elbow for the sake of discussion.
.evom ton seod gis eht
When you wrote \"i you used three bytes (assuming an ASCII-style one byte per character encoding) to represent one character. In contrast, Unicode represents ï as codepoint x00EF, which in UTF-8 ends up as two bytes, x00C3 and x00AF.
You should amend your quote to "you can represent English in 7-bits... just so long as you're willing to use more than 7-bits to do it."
1) unicode is better than having a hundred other encodes to debug
2)there's is nearly two billion chinese and Indians, who can't use your encoding.
3)I get just as much spam from US companies as I do foreign ones
i thought once I was found, but it was only a dream.
What kind of a flawed design is it where character encoding can impact security. The concept of scanning for unsafe strings is also flawed as in the case of virus scanning, as it only know about the stuff it knows about. This is another example of Ranums enumerating badness. If the SQL engine used only stored procedures then you wouldn't have to run a content scanner as the only thing coming over HTTP is DATA.
davecb5620@gmail.com
a few people trying to look posh may use the odd diacritic on a loanword or as a heavy metal umulat but really they aren't nessacery for english.
you can get down to 6 bits per character if you are prepared to do away with either most punctuation or mixed case.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
How na+AO8-ve!
Back in the Win95 days, I recall a stupid little exploit that would lock up a Win95 machine. The root of the problem, however, was in the TCP/IP code from BSD's source. Microsoft had used BSD's TCP/IP stack code in building one for Win95. I'm not here to complain that big bad commercial vendors are "stealing" from the open source community. I'm just suggesting that perhaps this is yet another example of how OSS has made yet another important, thought silent, contribution.
It's annoying to me when people suggest that OSS is sub-par in some way or another. It would be nice if there were a long list somewhere of all the more commonly identified examples of OSS contibutions to commercial code. Then it can be more conveniently shown that commercial code quite often depends on the derided OSS code.
Grandparent is correct; what these Floridans send doesn't qualify as English.
"I Know You Are But What Am I?"
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
The answer would seem to be -- sort of ... maybe. See http://www.njstar.com/tools/telecode/jim-reeds-ctc .htm.
Summary: For telegraphy, Chinese characters are assigned numeiic codes in radical-stroke count order. That's the way that Japanese, and -- I assume -- Chinese, dictionaries, are arranged.
It may seem inefficient to use 20 bits (sort of) to encode a character, but remember that each character is a word, not a letter, and that composite words like "Beijing" or "paleontology" are only two words. That means that most "words" will be either 2.5 or 5 eight "bit" characters. Conventional telegraphy is really a trinary rather than a binary code -- pause, short, and long, and the 'digits' differ in length -- so bit count isn't really all that accurate an analogy.
So, no, the Chinese language probably wouldn't have made the development of computers by the Chinese all that much more difficult than European languages did. And the classic Chinese numeric notation is not as convenient as 'arabic' notation. But it's much less unwieldy than say Roman numerals, so I don't think it would have been an insumountable hurdle either.
You can't see ANYTHING from a car, You've got to get out of the goddamned contraption and walk...Edward Abbey
Misuse of wchar_t? Care to elaborate? My only complaint with wchar_t is that is barely used at all. From what I've seen, programs that use wchar_t are shorter, more readable, and more secure.
Try out fish, the friendly interactive shell.
My experience with unicode and C is that it is painless when done right.
You only need two things.
1) Remember to call setlocale.
2) Use wide character wrappers around all system functions that don't already have one, e.g. wopen, wrealpath, etc.. Never ever directly use narrow character strings for anything.
Try out fish, the friendly interactive shell.
'Back in the Win95 days, I recall a stupid little exploit that would lock up a Win95 machine. The root of the problem, however, was in the TCP/IP code from BSD's source'
I assume you are referring to the ping of death. The root cause being a bug in the TCP protocol and occured on other platforms not using the BSD code.
was Another likely example of OSS?
davecb5620@gmail.com
How low can you go if you completely forgo proper spelling?
I've upped my standards, so up yours.
After reading through this carefully, it seems the fault is really with the webserver software (in this case, IIS). The problem is that normally a full-width character (such as FF1C in the example) and the regular character "<" are not equivalent, but IIS is translating the full-width form of a character into the regular character, so although the two forms were distinct before reaching the frontline filters, they are no longer distinct by the time it reaches application code running under IIS.
I guess whether you call this a fault depends on whether you think the webserver should be translating full-width characters to their equivalents. I tested a webpage, and both IE and FF do not consider "<" and "\uFF1C" (encoded in UTF-8) to be equivalent. The latter is displayed as a giant angle bracket, and does not work as the start of an HTML tag. I would think that the webserver should also respect this distinction. Anyone know more about full-width characters, or why they even exist?
"No one likes working in a hamster wheel, and your shop smells of cedar shavings from here." - TaleSpinner
First, only about five thousand characters are actually commonly used, with less than two thousand tones to represent those five thousand charcters. That gives rise to my second point, which is that spoken Chinese can be highly contextual (hence the propensity for puns and other wordplay).
My guess is that morse code would have evolved to be the same way that ASL simplifies language considerably. Each sequence would represent a different idea, or character, but every idea could pretty much be conveyed with a few hundred such unique sequences.
For computers, either there would have been a push to a standardized alphabet-like set, like bopomofo or even using roman characters a la pinyin, or 16- or 32-bit characters would be a necessity before computers became ubiquitious. Technology usually develops around human convenience, so I'm imagining that the latter would be more likely.
For input, it would be possible that instead of keyboards, handwriting recognition might be the defacto standard. I'm certain there would be some level of context-sensitivity and simplification though to make input short and easy. More likely, we'd still have the keyboard, but there'd be keys for each of the strokes, and keys for every radical. Which means perhaps 100 keys rather than a 40 keys to represent the whole language. Remember the red keyboard in that James Bond movie with Michelle Yeoh?
"If a nation expects to be ignorant and free in a state of civilization, it expects what never was and never will be."
About your point #2:
On linux (any unix really) you want to avoid wchars and wide functions like the plague.
The way to go for i18n is using utf-8 and bytes for character strings everywhere. (look into the gtk+ library for examples of this)
The whole wchar experiment has been declared a failure, and is deprecated for any usage really.
Great reply, thank you. I haven't used Windows for a few years, but it's good to keep up with this kind of thing, and I'm sure others can benefit from this information.
I am TheRaven on Soylent News
Brits tend to pronounce it BURN-urd, whereas Americans favor bur-NARD.
Promote proofreading. Don't mod up sloppy posts.
So how long til we find out that there has been exploitation of this vulnerability for X number of months for the sole purpose of stealing our WoW accounts!!!
Why steal someone's real identity when you can steal their uber virtual Undead Priest identity and sell it for 16 bucks.
News Reporters Make Tasty Polar Bear Treats!
Am I the only one who has noticed that since CERT partnered with the US Government, the response time on advisories has been much slower, and the details and depth of reports are less comprehensive? CERT advisories used to be a critical part of our security strategy. Now by the time the hit the mailing list (if at all), they're more of an afterthought.
Is there a better alternative to CERT now because it just isn't cutting it. I am familiar with Bugtraq and Security Focus. By the time CERT mentions something, usually it's actively exploited. It wasn't always like this but now the service isn't nearly as helpful to administrators.
Yeah, but according to a business week article, 1.847 billion of those chinese and indians won't buy your software, they'll just pirate it. So fuck it, let them write their own software. They can use however many bytes per character they want. Anyway, I miss plain ASCII. Much more elegant, and you can use char buffers as buffers for binary data without dicking around with lo-byte / hi-byte nonsense.
That comes as a complete surprise to me, and I thought I knew at least a little about Unicode and other character encoding schemes. The usual methods of encoding Unicode character points are UTF-8 (variable-length scheme where characters may be represented by anything from one to six bytes), UTF-16 (fixed-width double byte encoding), UTF-32 (fixed-length 4 byte encoding), and well there's UTF-7 and other oddballs. But the closest I've ever heard of "half width" and "full width" is in connection with Asian--specifically Japanese--characters. There are Asian character sets that have "half-width" and "full-width" variants. Though this is inconsistent with the original intent of Unicode, these character variants (each pair of which are really forms of the same character that have different widths) were defined as separate Unicode characters.
Maybe everyone else knows what they're talking about, and I missed some crucial piece of information...but I don't understand how mistaking one character for another is going to break anything--you'll just have the wrong characters. Anyway, are they talking about HTML content sent via HTTP, or URLS, or what? Can anyone explain this better? Or am I not supposed to understand it?
Great men are almost always bad men--Lord Acton's Corollary
Just a nitpick, in Chinese each character represents a syllable, not a word. Most characters do also correspond to words on their own, but this is not always the case (e.g. the various particles). Also, FYI, Chinese is not a monosyllabic language, unlike Thai for example.
We hope your rules and wisdom choke you / Now we are one in everlasting peace
Um, no. Those are needed for correct English spelling. The woman's name is Zoë, not Zoe. It's coöperate, not cooperate. Those aren't umlauts, either. It's called a dieresis.
The European Commision have just announced an agreement whereby English will be the official language of the EU rather than German, which was the other possibility. As part of the negotiations, Her Majesty's Government conceded that English spelling had some room for improvement and has accepted a 5 year phase-in plan that will be known as "Euro-English":
In the first year, "s" will replace the soft "c"... Sertainly, this will make the sivil servants jump with joy. The hard "c" will be dropped in favor of the "k". This should klear up konfusion and keyboards kan have 1 less letter.
There will be growing publik enthusiasm in the sekond year, when the troublesome "ph" will be replaced with the "f". This will make words like "fotograf" 20% shorter.
In the 3rd year, publik akseptanse of the new spelling kan be expekted to reach the stage where more komplikated changes are possible. Governments will enkourage the removal of double letters, which have always ben a deterent to akurate speling. Also, al wil agre that the horible mes of the silent "e"'s in the languag is disgracful, and they should go away.
By the 4th yar, peopl will be reseptiv to steps such as replasing "th" with "z" and "w" with "v". During ze fifz yar, ze unesesary "o" kan be dropd from vords kontaining "ou" and similar changes vud of kors be aplid to ozer kombinations of leters.
After ziz fifz yar, ve vil hav a reli sesibl riten styl. Zer vil be no mor trubls or difikultis and evrivun vil find it ezy tu understand ech ozer.
ZE DREM VIL FINALI KOM TRU ! ! !
Read the rest of this comment...
The notable difference between Chinese and English (or most other written languages) is that several English characters combine to form syllables, which combine to form words (i.e., we use an alphabet). In Chinese, each character corresponds directly with a word (each character is a logogram).
/. filters, consider the word zi4ran2. The zi4 syllable is a word, and means "from" or "since" (and is also used like "-ly" to form adverbs). The ran2 syllable is also a word, and basically means "correct" or "yes". The zi4ran2 combination means "nature" or "naturally". Like "insight", you might be able to kludge some sort of connection here, but in reality you just have to learn zi4ran2 as a separate word unrelated to its two syllables. It may have been a two-word idiom several thousand years ago; it's a two-syllable word now.
;-)
Actually, this is pretty much a myth that originated from people with very little knowledge of Chinese language and writing. In all the Chinese languages ("dialects";-), most of the vocabulary is two-syllable words, as in English. Three-syllable words aren't uncommon. The writing system is actually a sort of syllabary, and the meaning of most two-character words can't be inferred from knowing what the syllables mean as standalone words.
It's similar to how lots of English words, e.g. "insight", can be parsed as two words ("in"+"sight"), but this doesn't really help you understand what the word actually means. Or, an example that shows how such things evolve is the English word "upstairs". If I say I'm going upstairs and take the elevator, did I lie to you? Of course not, because "upstairs" doesn't mean going up stairs. It did a few centuries ago, but hasn't meant that during the lifetime of anyone alive now. Similarly, proto-Chinese of N thousand years ago may have been mostly single-syllable words, but this hasn't been true for at least the few thousand years that we have readable examples of the writing system.
For a Mandarin example, which I'll write in pinyin (or pin1yin1;-) to get past the
For an entertaining debunking of both this myth and a very common trope among Western pseudo-intellectuals and pop psychologists, read this article at languagelog. After chuckling at that particular bit of silliness about Chinese writing, you can find other articles there that go into the general problem in more detail. A number of experts in East-Asian linguistics regularly contribute to that blog, and they've been pushing for a campaign to debunk the nonsense that Westerners insist on saying about these languages.
Oh, well; I haven't yet heard any claim that Chinese doesn't have a word for "freedom". But I wouldn't be surprised. (Hint: the word starts with the same character as the above "zi4ran2", but has a different second character.
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
Thanks, that was a very useful reply. It's always nice to feel that I'm less stupid than I was at the start of the day ;)
.evom ton seod gis eht
[T]he classic Chinese numeric notation is not as convenient as 'arabic' notation. But it's much less unwieldy than say Roman numerals, so I don't think it would have been an insumountable hurdle either.
Actually, classical Chinese numbers are only slightly worse than Arabic notation (which apparently developed in India but was spread by Arab traders who knew a good accounting system when they saw it). The Chinese notation was far better than any of the Western number notations that the Arabic notation supplanted, such as the Greek or Hebrew notation. Roman was probably the worst notation ever invented, and nobody ever really used it for accounting.
The basis of the Chinese system was symbols for 1 to 9, and symbols for powers of 10. To illustrate with ascii characters, the symbol for 10 looks like a large '+' sign, so we can use + for 10, H for hundred, T for thousand. We'd write the number 5347 as 5T3H4+7. Unused powers of 10 are omitted, so 2007 would be 2T7. 1024 would be T2+4 or 1T2+4. And so on. There are symbols for a few more powers of 10, and they can be chained to get higher powers of 10, so HT could be used for 100,000.
Nowadays, most numeric work in East Asia is done using the Western version of Arabic notation. But you also see a hybrid form that uses the Chinese 1-9 characters plus the Western 0. Converting between this notation and the traditional Chinese notation is essentially trivial and can be done as fast as you can write the numbers. But for arithmetic on paper, the Arabic form (or Arabic with Chinese digits) is a bit simpler than the traditional Chinese notation, since using 0 as a place holder results in correct alignment in columns of numbers, and the digits 1-9 are a bit faster to write than the Chinese digits.
An interesting aspect of the Chinese system is that the basic symbols have alternate "fancy" forms with a lot more strokes. These characters have the property that you can't add strokes to convert them to a different character. So they're an anti-tampering, fraud-proof way of writing numbers. I don't know of another numeric notation with this feature. Asian financial documents have historically used these fancy forms of numbers.
Actually, the Chinese and Arabic notations are the 3rd and 2nd easiest numeric notation that various societies have invented. A few years ago, Scientific American had an interesting article explaining the Mayan number system, and included an explanation of why it was a lot easier to use than the Arabic system. For example, instead of the big multiplication table that we memorized in school, the Mayan system really only needs one rule: 5x5=15. (This makes sense if you understand that they used base 20.) The rest of the rules for adding, subtracting and multiplying consist of the techniques for "carrying" and "borrowing", and are essentially similar to what you do with an abacus.
But I suppose we're stuck with the Arabic system. It's good enough, really, for the remaining uses where we don't bother with a computer.
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
No, you haven't been the only one to notice that CERT has some timeliness issues when it comes to reporting on threats. Other CERTs, such as AusCERT, have the same sort of problem - particularly when you consider their public notification data (separate from their paid-for disclosure lists). Accepting that it takes time to analyse and report information, and accepting that they are disclosing to their fee-paying / sponsoring clients first, the recorded dates of information discovery are often significantly incorrect. This particular report comes as quite a surprise to us. We had always considered that variable-width encoding was relatively well understood by InfoSec companies, especially those that provide services in multiple languages. It always seemed more self-evident than HTTP-Request/Response splitting, for example.
The timeliness same problem also affects moderated sources such as BT and the various SecFocus sources, where there can be a several day delay between initial disclosure and appearance on those sources (if not longer - one particular list has recently developed a delay of > 1 week for new posts). Plus, you always get the problem of identifying what sources are accurate and relevant (hint: the CitiBank Screencap argument is about 2 years too late).
So, where do you look for additional resources? You could always look at companies like Secunia, FrSIRT, eEye, Symantec, or McAfee, but it is possible to time threat disclosure so that there is an approx 72 hour delay before they pick up on the threat, and there is always the question of coverage - McAfee will always have a focus on virus, worm and some malware threats.
Or, you could always use our services (http://www.beskerming.com).
We have a number of established free and fee-based services that deliver timely, relevant and accurate information about current and emerging threats. They effectively cut out the irrelevant noise that is most of the massive amount of data (across a number of different information channels) that is Information Security disclosure.
We have no vendor affiliation, do not rely on sponsorship or advertising in order to deliver our services, and strive to be platform neutral when analysing and reporting on issues. We know that our services are already being used by companies to augment their Incident Response Team information sources (as well as to validate the data coming from their more expensive, less-timely data sources), and for some clients our services form the core of their security response strategies.
Why not get in touch? We're more than happy to have someone chat to you about your InfoSec needs.
InfoSec that matters, when it counts.
***An interesting aspect of the Chinese system is that the basic symbols have alternate "fancy" forms with a lot more strokes. These characters have the property that you can't add strokes to convert them to a different character. So they're an anti-tampering, fraud-proof way of writing numbers. I don't know of another numeric notation with this feature. Asian financial documents have historically used these fancy forms of numbers.***
I'd never thought about it. Not only are you right, but Chinese numbers -- even the basic forms -- are much less ambiguous than our familiar 'arabic' forms. I was once involved in a project that tried to OCR the amount field on checks. Amongst the many problems, some people manage to handwrite 1, 2, 4, 7, 9 in shapes that are virtually identical. Try decoding that sort of check. The biggest suprise. Courier typeface 5s and 6s differ only in a couple of dots. Even people sometimes can't distinguish the two when typed/printed with an old ribbon.
You can't see ANYTHING from a car, You've got to get out of the goddamned contraption and walk...Edward Abbey