Check your Windows 10 block settings

[Tony Hwang]

Hmmm, I bought a new car with my card. When dealer hesitated I was going to walk out the door. They don't like cash sale or full payment with CC. They make better money on financed cars.

[Tony Hwang]

May I ask how old you are?

[Roger Blake]

Old enough to have been paying cash at the butcher shop and the baker when real silver coin was still in general circulation.

[Tony Hwang]

I still see some silver coins from now and then in our till. That does not mean you're old.

[Roger Blake]

I'm talking about when they were all silver. When's the last time someone paid for something at your establishment with silver dollars? I used to use 'em all the time, they were nothing special.

[Don Y]

The *worst* is someone who fishes around for a checkbook... then starts hunting for a pen... then thumbs through *carbons* of previous checks to find check #7125... then starts writing out the check... then discovers that the ink cartridge is "retracted"... then discovering that the pen is *dead*... then hunting for scrap paper to "scribble on" to "reprime" the pen... then asking the cashier for a pen... then asking who the check should be paid to... then...

and, EVENTUALLY, getting *pissy* that someone waiting makes a comment about how SLOW they are!

[Roger Blake]

I'm with you there. I was never inclined to use checks in a store, just seems like a PITA with little if any benefit.

[Tony Hwang]

Hey, I am up here in Canuck land. I never carry coins of any kind. I don't want holes in my pants pockets. Smart phone and CC is all I need.

[Tony Hwang]

Maybe it is easier to see white cars day or night. One of my BIL (wife's side) always buys/drives white cars. Once I heard from a painter, matching white or ivory black is most difficult.

[Roger Blake]

You wanted to know how old I was - while I'm loathe to provide specific personal information I wanted to give you a ballpark indicator. Another is that I'm old enough to have watched 'I Love Lucy' and 'The Honeymooners' during their original run, on a TV set like this one:

(I actually still have a set similar to the above, though it needs to be serviced.)

If you want the details of your life to be an open book that is totally up to you. On the other hand, cash is freedom and privacy. I'll be sticking with it.

[Don Y]

Then spend some time and find examples that *aren't*. I have no skin in this game. Exploits will *always* be in "compiled code" -- that is being tricked into doing something that it wasn't properly designed to AVOID!

Have oyou ever read the descriptions for the updates windows pushes? Ever notice how many claim to be to fix a "security vulnerability"?

This is the polite way of saying the developer screwed up and didn't anticipate someone MISUSING the code he wrote. How does someone misuse code? Ans: they present it with "inputs" that have been crafted to exploit unexpected patterns in that data. I.e., violating basic ASSUMPTIONS that the developer made -- inappropriately.

I received a nastygram from a bank many years ago claiming that they would have to withhold a portion of my interest income because I had not provided them with my SSN. Yet, my SSN was printed right below my name ON THAT LETTER!

Guy who wrote the "code" to decide who should get those letters assumed "0" (in the corporate database) would indicate "no SSN". And, I'm sure he tried a test case with a bogus user having a SSN of "0".

But, he implemented his test in such a way that anyone whose SSN

*began* with '0' would be seen as having *no* SSN on file. Those of us who had SSN's issued in the Northeast ALL have SSN's beginning with '0'. Of course, as the bank was in Colorado and most customers were probably from that area (with SSN's that reflected that part of the country), it took a while for the software to stumble on folks (like me) that tickled that bug.

That bug could just as easily have decided to mail me an interest payment, etc.

Sit down with Google and an hour of *your* time and I'm sure you'll be able to find lots of exploits. PDF's are a habitual source of vulnerabilities -- largely because PostScript is a Turing-complete programming language (and PDF's are based on PS).

Thirty seconds with google: CVE-2014-6332

"The IBM X-Force Research team has identified a significant data manipulation vulnerability (CVE-2014-6332) with a CVSS score of 9.3 in every version of Microsoft Windows from Windows 95 onward"

"The bug can be used by an attacker for drive-by attacks to reliably run code remotely and take over the user?s machine ? even sidestepping the Enhanced Protected Mode (EPM) sandbox in IE 11 as well as the highly regarded Enhanced Mitigation Experience Toolkit (EMET) anti-exploitation tool Microsoft offers for free."

All input causes a program to alter its behavior. So,

*any* input can conceivable lead to an exploit in an inadequately designed application.

Passing letters to a program expecting digits can cause that program to barf. The Y2K bug could manifest in many ways based on how the date processing code responded to the "unexpected" '2' in the leftmost position (I've seen dates displayed as "1 January 19A0")

Passing too many characters to a program expecting a lesser number can cause it to barf (buffer overrun).

If "barf" results in the contents of some portion of memory being overwritten, then you can carefully craft an exploit that puts "specific" values in that memory

It's a semantic difference with no consequence. Doesn't the CPU's *hardware* "interpret* the bytes that are fed to it via it's bus interface unit? If I write a simulator and feed it the same byte sequence, it is clearly interpreting the bytes yet the result is the same.

A program processing input is a PROCESSOR. It is interpreting the input and REACTING according to rules that are encoded into its implementation. Just like a CPU interprets opcodes and REACTS according to the rules encoded in its implementation.

[You do realize that most CPU's, nowadays, are microcoded? I.e., there are little PROGRAMS running in response to each byte fetched. These programs *emulate* the legacy instructions that we think of as "x86 machine language"]

No. PDF's encapsulate PostScript. Sit down with a PS manual and WRITE A PROGRAM... IN POSTSCRIPT... to print the numbers from 5 through 27. Then, write a PROGRAM to convert any numeric entry to its textual equivalent; e.g., 123 --> one hundred and twenty three.

Do this with Acroscript disabled!

Better yet, take that "program" and send it to your PostScript

*printer* (which has no concept of Jscript!). You'll find that it generates the same correct output!

What do you mean, like files that compromise the computer WHEN THE POWER IS OFF? When the computer is *on*, it is executing code. The code that it executes was created by a fallible human being. That developer's ASSUMPTIONS are embodied in the code. Exploits take advantage of these assumptions to trick the code to do things that it wouldn't otherwise do -- if presenteed with CORRECT (expected) INPUT.

Sure! If the part of the browser that parses the HTML to recognize "blue" figures the only colors that will ever be specified in an HTML file ("input" to the browser) are red black chartreuse yellow pinkpolkadotted coffee and, as a result, pinches pennies and allocated a buffer to store the color name and allows that buffer to hold

15 characters (the length of the longest expected color name -- "pinkpolkadotted"), then I can create a web page that says "draw a table with a background that has the color DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD". The sloppy browser code sees the "color" keyword and then gobbles up the next "word" -- expecting it to be a color. Since it KNOWS the longest (legal) color name is "pinkpoladotted", it won't be prepared for those extra 40 characters (there are 55 D's in the above example).

So, whatever resides in memory AFTER that buffer that stores the color will be overwritten with 40 D's (the first 15 D's will reside in the buffer).

This might have amusing effects. Or, might crash the browser. Or...?

I might, instead, have to pass a string of 5000! D's in order to ensure something much farther away from that color bufer gets clobbered. But, I can play around all day to see what gives the results I seek -- I've got the same browser available on *my* computer and I can actually WATCH to see what gets clobbered *inside* the browser.

Or a fault in the browser's code itself!

In your last post, you suggested VLC was a way you could *protect* yourself from browser vulnerabilities. What's your *new* scheme given that VLC is vulnerable? Are you sure your alternative won't also have some OTHER vulnerability?

So, I embed the instructions in the video file to do the damage that I want OFFLINE! Remote exploits are more precious to a hacker because *he* can then control the actions of your machine -- instead of embedding those actions unconditionally in the exploit.

[The days of erasing hard disks as an exploit are long gone]

None of the Iranian centrifuges were internet connected...

[Tony Hwang]

Both you and the TV set is antique, dinosaurs, LOL! I am guessing I am as old as you are.

[Roger Blake]

Always tough to tell in this medium. I've found most of the smartphone crowd tend to be youngsters but there are always exceptions.

[G. Morgan]

Enterprise version.

[rbowman]

I just write a check. The last car I bought the salesman kept launching into his financing deal even though I'd made my intention to pay cash clear. He just couldn't help himself; it was part of his programming.

The last time I financed was back in '80 when they had a $99 down 0% deal to try to move cars off the lot. It was GMAC's money and boosted my credit rating.

I'ts just how I was brought up. You save the money and then you buy what you want; you don't go in hock for it.

[rbowman]

That really burns my butt at Costco. You sign the check and the cashier runs it through the machine that prints the rest but you always have half blind, half senile Aunt Millie trying to fill it out for herself.

[rbowman]

That works until it doesn't. Around here it isn't hard to find stores that don't do plastic and cell reception gets spotty outside of town and the interstates.

[rbowman]

My current car is arrest me red. Not my favorite color but when I bought it Japan was undergoing a little nuclear meltdown so I took what was on the lot.

My least favorite is that gray that was popular. Fog, or even the mist kicked up on the road when it's raining makes them banish entirely.

[Mayayana]

| Have you ever read the descriptions for the updates windows | pushes? Ever notice how many claim to be to fix a "security | vulnerability"? | | This is the polite way of saying the developer screwed up and | didn't anticipate someone MISUSING the code he wrote. How | does someone misuse code? Ans: they present it with "inputs" | that have been crafted to exploit unexpected patterns in | that data. I.e., violating basic ASSUMPTIONS that the developer | made -- inappropriately. |

That's an interesting point. If you look into the details of those fixes you'll find, in the vast majority of cases, that it's like your PDF, MP3 and MP4 issues: The actual hack involves javascript. Microsoft doesn't generally focus on that because they're a big corporation trying to "monetize" the Web. They don't want people disabling javascript. They even play down ActiveX. IE always depended on ActiveX. MS just couldn't afford to write the truth: "Warning! New IE attack! You should disable ActiveX because ActiveX is dangerous. It was a big mistake. Sorry."

Instead they have a section, way down the page, titled "workarounds", in which they beat around the bush.

The javascript issue is like the elephant in the room. It's obvious to anyone who takes a look. It's common sense that executable code in webpages can never go along with security. But nobody wants to hear that. The website owners want "rich content" and trackability. The visitors want convenience.

You've brought out a lot of interesting points in this discussion with your devil's advocate style of discussion, but I think that at some point that misses the point. You're making a big deal out of the rare exception. Javascript is by far the biggest problem. Maybe 90%. Almost all the rest is things like Java, or maybe an occasional MS Office attack that doesn't need script. The data is online. Cisco put out a report awhile back, for instance. Anyone can read it for themselves:

0-day browser hacks, used by everyone from the NSA to Russian criminals, are also mainly javascript issues. Typically it's javascript running in an iframe. Cross site scripting.

Script, script and more script. To keep focusing on the .5% that's not script related, and that is highly unlikely in the first place, is to skew the facts. (The VLC player vulnerability is good to know about, but it's very unlikely to ever be a risk. It's unlikely to ever even be exploited, because VLC isn't widely distributed. Even if it were exploited, I don't use it online. (Likewise, I would never install a PDF browser plugin.) And there's also context: Exploiting VLC would require that I download a video from a dubious source.

What makes Adobe's stuff so bad is threefold:

1) Adobe has a bad habit of jacking up functionality with javascript at the cost of security.

2) Adobe has a long history of trying to create a proprietary Web by force-installing their plugins. (Acrobat Reader installs the PDF browser plugin, with Adobe pretending that PDF is a webpage format.)

3) Adobe has been very successful at flooding the market in attempts to make their products ubiquitous. Acrobat Reader is nearly universally installed because they've been giving it away like grocery store coupons since the 90s. Flash is also nearly universal.

Those three things have resulted in the vast majority of people having Flash and Acrobat Reader *and* with both running in the browser. That's an important distinction. Their ubiquity, their use of script, and the fact they run in the browser, all combine to make them the most common attack targets.

*Not using the most popular brand is one of the best security measures because it's not a good strategy for hackers to target software with a limited market.*

| > I've never heard of any vulnerability in HTML. | | Thirty seconds with google: CVE-2014-6332 |

Another 30 seconds turns up this:

"This vulnerability can be exploited using a specially-crafted web page utilizing VBscript in Internet Explorer."

It's an IE-specific bug, requiring script. It has nothing to do with HTML. (No one should *ever* use IE online in the first place. It's too closely linked into Windows.)

This is what I mean about your devil's advocate approach. You're trying to find any tiny exception to the rule. A tiny exception does not negate the rule. And what you're finding are not even exceptions. By trying to carry out a good debate you're obscuring the one critical point: The single best thing you can do, by far, is to disable javascript. No other security measure, even using anti-virus software, comes close to the protection afforded by disabling script.

[Mayayana]

| >Does anyone know if Microsoft will be offering a paid version of Win10 that doesn't spy on us? | | Enterprise version. |

Not exactly. I don't know whether they still sell the so-called Enterprise version as a retail disk or not. They may. Either way, the only version exempt from forced updates is the corporate install under a Software Assurance license. In other words, if you want to be exempt from the "consumer EULA" you need to contract with Microsoft. For that you need to be making a very big order. Even then, it's not clear how much spying can be stopped. You'd need to ask some corporate IT people who've had time to look into it. The only thing I've heard for certain is that the corporate contract allows IT people to block automatic updates.