On 10/18/2015 6:52 PM, Mayayana wrote:
| The exploits I mentioned previously don't require any
| "remote software" to be executed from the 'net. *But*,
| as each of these non-ASCII-text files requires something
| to *interpret* their contents (as a photograph, audio
| clip, video clip, etc.) then those non-ASCII-text files
| are, essentially, *programs*! They control the behavior
| of their respective "decoders" when you apply those decoders
| to those files.
That's not true. The exploits you listed all
involve a weakness in executable code -- either
compiled binaries or script. Most involve javascript.
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!
Many of those *also* require a binary like Flash.
The rare exception would be something like the
gdiplus.dll bug that could be exploited with JPGs.
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.
(Gdiplus was fairly new at the time.) Data files that
are not interpreted as executable -- whether text
or not -- are almost never a risk because they're
not doing anything. (Again, I'd be interested to
hear if there are any examples besides the one-time
JPG issue, which was many years ago.)
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).
I've never heard of any vulnerability in HTML.
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."
It defines graphical layout. It's not interpreted
as executable code. It's sometimes possible to
crash a browser with faulty HTML, but that's just
a case of "choking" the software. There's no
executable code involved.
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
| If I email you a receipt for a purchase
| as a PDF, then the act of opening it means your "PDF decoder"
| has now been tricked into "interpreting" the information
| embedded in that file (just like a computer interprets a
| computer program).
You're misusing the word interpet. A computer
doesn't interpret a program. The program itself
accesses the CPU, RAM and disk.
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"]
Script is text
that's interpreted as executable code, but that
makes it just like a compiled program, in that
the interpreter is a program acting under the
direction of the script. A PDF is not interpreted
as executable code. What the PDF reader gets from
the PDF data is information about text, fonts,
colors and layout. The problems with PDF are due
allowing javascript in PDFs to run.
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!
| The browser *is* executable code! The OS is executable code.
| The JPG decoder is executable code. The PDF reader is executable
| code. Anything that *does* anything does it by executing code!
I don't know how many ways I can explain it.
As I said, I'd be interested to know if you find
any vulnerabilities that do not directly involve
executable code.
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.
They're few and far between.
In other words, a browser is, of course, executable
code, but you can't hijack it by telling it to draw
a table with a blue background.
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 DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD DDDDD".
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.
A browser is
hijacked by getting it to run executable code --
via the javascript "engine" or a faulty plug-in.
Or a fault in the browser's code itself!
| Adobe crap at all. Don't enable script. Don't install Java.
| Don't run videos and music in browser plugins like Flash.
| Don't enable script in your PDF viewer.
| (For me this is easy. I don't like things moving on webpages
| while I'm trying to read. If I want to see a video I'll
| download it, so I can save a copy, and play it in VLC. If
|
| http://www.zdnet.com/article/vlc-vulnerabilities-exposed/
| "Vulnerabilities have been discovered in some versions of the
| popular VLC media player which may allow a cyberattacker to
| corrupt memory and potentially execute arbitrary code."
|
http://www.saintcorporation.com/cgi-bin/demo_tut.pl?tutorial_name=VLC_vulnerabilities.html
That's interesting. It's good to know about
such things. But I'm not going to lose
any sleep. I'm not using a VLC browser plugin,
and there's very little motive for someone to
put a video on youtube that will attack my
system offline. Especially given that I don't
download wacky cat videos from random posters.
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?
| Note that it doesn't matter if you run VLC from your browser or
| download the file and run VLC separately.
| "Vulnerabilities in VLC allow for remote code execution or
| denial of service. VLC also has a remote code execution
| vulnerability in the web interface."
Remote means remote. If you download a file
and play it in VLC that's not remote execution.
Remote would mean playing it via webpage or
some other way of accessing it from a remote
location.
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...
| It's like the admonition from my youth regarding unwanted
| pregnancies: the only SURE contraceptive is ABSTINENCE!
| I.e., the only sure way to avoid these vulnerabilities is
| to NOT import anything that you didn't create yourself.
I suppose that in the most extreme interpretation
you're right. I've decided that having sex carefully,
with my post-menopausal ladyfriend, is a "risk" I'm
willing to take. Good luck with the inflatables. 