Intego Trojan Warning

Nothing really ever changes...

Security firms can't run a virus warning systems because when they
are both the source of warnings and the seller of products and
services that benefit from the publicity, then it's a conflict of
interest. The manufacturer (e.g. Apple) can't do it because when
they are both the source of warnings and the seller of products that
may be hurt by the publicity, then that's a conflict of interest too.
The government (CERT) can't be relied upon because they don't have
the resources or the mandate to handle such problems. Un-moderated
bulletin boards are no solution because these boards might contain
both real and fake warnings (or the viruses themselves). News
organizations can't do it because half of them are motivated by greed
("bad news sells"), and the rest couldn't care less (about the Mac
for example). At the same time, because security problems are so
rare on the OSX platform (non-existent actually), there really is no
feasible business model for Macintosh security (as there is on the
Windows platform). Even if this situation were to change, we could
not hope for a more effective anti-virus infrastructure than there is
presently with Windows, which is terrible.

I conclude that there are no good preventative measures that can be
taken. If a virus causes damage, or if a false warning about a virus
causes damage, then all persons and organizations that might have
been in a position to prevent such damage will appear to be either
dumb or corrupt or both. No one will have possessed actionable
intelligence that might have prevented the damage, and all
"responsible" persons will be presumed to have been derelict in their
duties. The answer, in my opinion, is preemptive action.

Imagine if you will the real world with someone threatening to blow
up the World Trade Center. The mere threat (no evidence of an actual
attempt) would today be considered a crime. The perpetrators would
be subject to prosecution if they are successful, and they could also
be prosecuted for any and all preparations, as functionaries in
"organized crime", or even preemptively as "war criminals".

The creators of real viruses, of "benign" or "concept" viruses, and
the issuers of false warnings based on them are all criminals, even
terrorists. Some in the information security industry have a theory
that good fences make good neighbors and that anarchy is mother of
goodness. They think that rogue code-breakers and virus writers like
the authors of the "Trojan horse" announced by Intego are doing us a
real service by testing our defences. To me, that's like
congratulating the fellow who fails in his robbery attempt but who
does cause his neighbor to implement a more intensive security system.

Virus writers and rogue code-breakers should be handled the same as
any other "terrorist". Like it or not, the recognition, codification
and prosecution of crime is a time-proven way to successfully build
civilized human society. If the creators of viruses can be caught and
vigorously punished, then that would be the best solution.

H.

On 4/15/04 9:35 PM, "Jochen Wolters" <jochenpolytropia.com> wrote:

> Probably the easiest approach would be to add some visual indicator to
> an application's icon. Just like that little arrow in the lower left
> corner of an icon indicates an alias, maybe a little "X" could indicate
> a Cocoa or Carbon application, a little "9" a Classic app.

Nice idea - but what about Carbon apps that can run in Classic - a 9/X?

In any case, I agree it is a good thought...
 
Kirk
 
        My new e-book: Take Control of Users and Accounts in Panther
          http://www.tidbits.com/takecontrol/panther/users.html
  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  . . . . . . . kirkmcelhearn.com | http://www.mcelhearn.com . . . . . .
  . . Kirk McElhearn | Chemin de la Lauze | 05600 Guillestre | France . .

--- begin forwarded text

From: Alex <alistsprint.ca>
Date: Thu, 15 Apr 2004 07:27:04 -0700

Regarding "Mac OS X Trojan Technique: Beware Geeks Bearing Gifts"
(TidBITS#726/12-Apr-04)

> "[...] the same technique could be used with GIF and JPEG files,
> and QuickTime movies (true, but irrelevant)."

You may know better, but I believe that is incorrect; the same
technique could _not_ be used with GIF and JPEG files, and QuickTime
files; nor could it be used with MP3 files containing ID3v1.x tags.
IMHO, it can only be used with MP3 files containing ID3v2 tags. Two
reasons:

(1) Only the ID3v2 spec allows for tags large enough to contain a
sufficient number of lines of code. The ID3v2 tag may contain frames
of up to 16MB for a total of up to 256MB!

(2) Only the ID3v2 spec allows for the encapsulation in the tag of
_any_ kind of file, including executable binaries. This is precisely
what Bo's p-o-c took advantage of. I don't see how an executable Mac
binary (i.e., not compressed and encoded) can be hidden in a JPEG,
GIF, or QuickTime tag.

> "[...] downloading a raw MP3, JPEG, or GIF file from an FTP or
> Web site (or one of the file sharing networks) is unlikely to
> expose you to an MP3Concept Trojan horse because Macintosh
> resource forks aren't transmitted when such files are downloaded
> unless the file is first encoded [...]"
>
> "[...] email programs will use the AppleDouble or BinHex
> encodings to ensure that a file's resource fork is protected."

Equally important is Mac metadata, namely the type code. The whole
trick relies on the fact that Finder determines the file type from
the type code (hidden to the user), and, only if that is absent, from
the filename extension. So, if the Mac metadata, specifically the
"APPL" type code, is lost (and, unless specifically encoded, it
always is, because other OSs do not understand it), then the
malicious code is still there, and the cfrg resource may still be
there, but Mac OS won't execute it when the file is double-clicked.
Hence derives a simple and obvious method of neutralizing the threat.

f
--- end forwarded text

On 4/12/04 10:48 AM, "Dick Rucker" <rruckerbellatlantic.net> wrote:
> What's been demonstrated is what can happen when file system designers try
> to cram the name of a file and and its type into the same meta-data field
> and then hide the latter half of the field's contents from the user.

Actually, this specific "exploit" is made possible by the fact that OS X has
*two* ways to designate a file type -- a three-character file extension in
the file name (which, in this case, tells iTunes to play the file as an MP3)
and a legacy four-digit "file type" code (which, in this case, tells OS X to
execute the file as an application) -- as well as by the fact that the
proof-of-concept file is a legacy application with a resource fork that
tells the OS where the "malicious" code is at. The MP3 concept file wouldn't
play as an MP3 in iTunes while at the same time executing code as an
application unless it has both an MP3 file extension and an APPL file type,
and it couldn't execute the "malicious" code -- located at an unexpected
location in the data fork -- without the resource fork telling the OS where
that code is at.

Of course, OS X (like OS 9) is vulnerable to any expoit where a malevolent
app is made to look like a document and then executes when the user tries to
open it. This particular exploit just so happens to actually *play* the MP3
file in iTunes (or whatever your chosen MP3 player might be), as well.

>(2) Only the ID3v2 spec allows for the encapsulation in the tag of
>_any_ kind of file, including executable binaries. This is precisely
>what Bo's p-o-c took advantage of. I don't see how an executable Mac
>binary

It's not necessary that the metadata tag be designed for executable
data. Any tag that can contain a big enough sequence of bytes, and
that isn't likely to be accessed when displaying the content could
serve as a container for a program. You also have to be careful
about file formats that might allow extra data beyond the defined end
of the file. Also, an application can have more than 1 code
fragment, so it might be possible to split the program up over
several tags.

>filename extension. So, if the Mac metadata, specifically the "APPL"
>type code, is lost (and, unless specifically encoded, it always is,
>because other OSs do not understand it), then the malicious code is

Any encoding that preserves the resource fork will almost certainly
preserve the type code. Eliminating the resource fork is also an
effective defense, since that eliminates the CFRG resource which
describes how to find the executable code.

--
Larry Rosenstein
lsralum.mit.edu

On 4/16/04 2:47 AM, "Dan Frakes" <DanFrakes.org> wrote:

> The MP3 concept file wouldn't
> play as an MP3 in iTunes while at the same time executing code as an
> application unless it has both an MP3 file extension and an APPL file type,
> and it couldn't execute the "malicious" code -- located at an unexpected
> location in the data fork -- without the resource fork telling the OS where
> that code is at.

I removed the .mp3 extension and dragged it into iTunes and the file played
just fine. Apparently, the reason it opens iTunes and plays itself is _not_
because of the extension, but because the codes tells it to...

Kirk

              Co-author of Microsoft Office v. X Inside Out
                http://www.mcelhearn.com/insideout.html
  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  . . . . . . . kirkmcelhearn.com | http://www.mcelhearn.com . . . . . .
  . . Kirk McElhearn | Chemin de la Lauze | 05600 Guillestre | France . .

On 4/15/2004 11:26 PM, "Kirk McElhearn" <kirklistswanadoo.fr> wrote:
>> The MP3 concept file wouldn't
>> play as an MP3 in iTunes while at the same time executing code as an
>> application unless it has both an MP3 file extension and an APPL file type,
>> and it couldn't execute the "malicious" code -- located at an unexpected
>> location in the data fork -- without the resource fork telling the OS where
>> that code is at.
>
> I removed the .mp3 extension and dragged it into iTunes and the file played
> just fine. Apparently, the reason it opens iTunes and plays itself is _not_
> because of the extension, but because the codes tells it to...

If you drag it into iTunes, it will play just fine even without the .mp3
extension since it's a valid MP3 file. I was referring to double-clicking
the file in the Finder, the method by which the "exploit" is intended to
work. When you do that, it will both launch as an application and be opened
by OS X in your preferred MP3 player because it has both an APPL file type
and a .mp3 extension.

--
----------------------------------
Get some Mac OS X Power Tools!
Second Edition available April 22
<http://www.MacOSXPowerTools.com/>
----------------------------------

At 1:32 PM -0700 4/16/04, Dan Frakes wrote:
>work. When you do that, it will both launch as an application and be opened
>by OS X in your preferred MP3 player because it has both an APPL file type
>and a .mp3 extension.

There's nothing in the OS itself that causes a double-click on a
single file to do both of those things. To the Finder, the file is
an application, and double-clicking it launches it as an application.
My interpretation of the exploit was that the application would then
cause the MP3 file to play by, for example, sending an Apple Event to
iTunes.

Previously, you said:

>Actually, this specific "exploit" is made possible by the fact that OS X has
>*two* ways to designate a file type -- a three-character file extension in

but I don't think that's quite right, because the same exploit would
work on older versions of the Mac OS which doesn't use the extension
as an indicator of the file type. At the OS-level there's no
ambiguity about the file type; it is definitely an application. The
real issue is that applications such as iTunes that deal with
cross-platform files ignore the file type code, because it might not
be set. They either open all files or look at the extension. (They
could look inside the file, but that can be expensive.) A simple
change Apple could make it for iTunes to not open applications.

The bigger contributing factor is that the CFM executable format
makes it easy to store code anywhere in the data fork, which makes it
easy to create 1 file that looks like both a legitimate MP3 and a
legitimate application. (I believe that was done to allow for
multi-architecture binaries that contain both 68K and PowerPC code
fragments.) I don't know if this kind of thing is possible on other
OSs.

Even if all these issues were taken care of, it wouldn't eliminate
trojans, which is why I think this whole issue has been blown out of
proportion. You could still have a trojan application that looks
like an MP3 file and when launched tells iTunes to play an existing
track in the library. Or it could write an MP3 to a temp directory
and play that. These behaviors aren't as stealthy as having the same
file act as a legal MP3, but many users wouldn't notice and as soon
as the app is run the damage is done.

--
Larry Rosenstein
lsralum.mit.edu

At 9:54 pm -0700 18/4/04, Larry Rosenstein wrote:
>The bigger contributing factor is that the CFM executable format
>makes it easy to store code anywhere in the data fork, which makes
>it easy to create 1 file that looks like both a legitimate MP3 and a
>legitimate application.

Code doesn't have to be in the data fork. It's entirely possible to
have an application with all the code in the resource fork, allowing
the data fork to be a valid file without any extra data in it at all.

And this isn't just the CFM format. 68k applications were like this
from the start of Mac OS.

Apart from the cuteness factor of putting the code in an ID3 tag,
there's nothing new in this demonstration.

regards,

Paul

--
Paul Durrant, Durrant Software Limited, Reg.Co.No.: 2612332
Custom XTensions for QuarkXPress since 1991
82 Earlham Road, Norwich, Norfolk, NR2 3HA.
<http://www.durrant.co.uk/>

> To the Finder, the file is an application, and double-clicking it
> launches it as an application. My interpretation of the exploit was
> that the application would then cause the MP3 file to play by, for
> example, sending an Apple Event to iTunes.

Exactly. From the original posting by Bo Lindbergh:

"The PowerPC code fragment is stored as a general encapsulated object
inside the ID3 information. It tries to locate iTunes and tell it to
open the file as audio, displays an alert, and then quits."

<http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF
-8&safe=off&selm=blgl-5D750C.02150821032004@news.bahnhof.se>

In other words, it is the MP3Concept application(!) itself that makes
iTunes play the file, _not_ the OS (or, rather, the Finder).

>> Actually, this specific "exploit" is made possible by the fact that
>> OS X has *two* ways to designate a file type
>
> but I don't think that's quite right, because the same exploit would
> work on older versions of the Mac OS which doesn't use the extension
> as an indicator of the file type.

Again, correct: the "trojan" runs on OS 9, as well, so it cannot, and
does not, rely on technology that is only available in X.

> A simple change Apple could make it for iTunes to not open
> applications.

That would not make the OS any safer, IMHO, since playing the music
portion only serves as disguise for the true nature of the "trojan."
IOW, the problem already starts when the user double-clicks the file,
not when iTunes playes the MP3 inside the file.

Probably the easiest and most obvious way to address this issue is to
clearly identify applications in all possible views in the Finder as
has been discussed in this thread earlier.

Jochen.

A good idea...

cheers... -Adam

--- begin forwarded text

From: Borja Marcos
Subject: Mac OS X "trojans"
Date: Wed, 21 Apr 2004 11:50:40 -0700

        Hello,

        I have read your excellent article about the horribly
dangerous, lethal mutant viruses/Trojans/worms, etc for the Macintosh
and how desperately we need to buy an Intego VirusBarrier. :-)

        Well, now seriously. I am working on the security field since
1991 more or less, and this kind of issue is almost as old as
computing itself. Can a user trust what he/she sees?

        Some years ago there were issues with web pop-ups, as they
were potentially dangerous. How many users would happily enter their
email username and password on a web pop-up resembling the Mail.app
login window? I guess many would do it.

        There are now two documented ways to trick a user to clink an
application. The "Intego way" and the "false dot" way. There is a
simple third way: set the file name to one or more spaces, and put an
icon which includes a false name, *drawn* as part of the icon.

        The list of possibilities is almost endless, I guess...

        My idea to prevent this would not be intrusive, and I think
it would work and it is simple: What about changing the shape of the
mouse pointer whenever the user placed it on an application? It could
be an X, similar to the X Window default pointer, for example. Or it
could be more elaborate, being a different shape *and* a different
color if it was actually the first time the user executed that
particular file.

        The idea is very simple, probably you have already seen it :-)

        What do you think? I am going to send this to Apple security,
but perhaps seeing it published in TidBITS would help to convince
Apple :-)

        Best regards,

        Borja Marcos.

--- end forwarded text

--
Catching up from vacation. Replies will be delayed and concise.
--
Take Control of your Mac! Visit: http://www.tidbits.com/takecontrol/
_____________________________________________________________________
Adam C. Engst: I publish TidBITS, write books, and make sure the
acetidbits.com right people know each other in the Mac industry.
Me: http://www.tidbits.com/adam/ TidBITS: http://www.tidbits.com/

At 18:59 -0700 UTC, on 2004/04/25, Borja Marcos wrote:

        [Way to indicate to user that he's about to launch an app]

> What about changing the shape of the
> mouse pointer whenever the user placed it on an application?

That ignores the user can also launch an executable from the keyboard (arrow
keys to navigate and Cmd-o to launch). Besides, even when the mouse cursor
would already changed when it _hovers_ over an executable, there's a good
chance it's too late already. It only takes a split second to position the
mouse above something and double-click it - you'd only register the mouse
cursor change when it is too late already.

The earlier suggestion of having an executable's icon indicate its
executableness makes more sense to me. A changing mouse cursor wouldn't hurt
as an additional indicator, but it shouldn't be the sole indicator.

--
Sander Tekelenburg, <http://www.euronet.nl/~tekelenb/>

> My idea to prevent this would not be intrusive, and I think it
> would work and it is simple: What about changing the shape of the
> mouse pointer whenever the user placed it on an application? It could
> be an X, similar to the X Window default pointer, for example. Or it
> could be more elaborate, being a different shape *and* a different
> color if it was actually the first time the user executed that
> particular file.

I prefer the OS to change the icon slightly on executable files (much
like many UNIX users change their directory listing colors to show
executable files in a different color.) The reasons are fairly minor:

a) Changing the cursor means the OS has to continually examine files you
mouse over. This requires file/processor usage just when mousing across
the desktop to go to the dock or another window. Changing the icon only
requires file/processor usage when the file is created on disk, not
every time it's moused over.

b) slightly less minor -- you have to put your mouse on a file before
finding out if it's executable or not. The modified icon method visibly
changes the icon which can be checked quickly, without having to move
the mouse to the icon first.

[I don't think the cursor idea is perfect, but I don't think changing icons is likely to make much difference. After all, icons can be faked easily, which isn't true of the cursor. And as much as it is processor time, for all Aqua is doing, changing a cursor seems minor. -Adam]

Kevin

On 4/27/04 8:43 PM, "Kevin van Haaren" <kevinvanhaaren.net> wrote:

>> My idea to prevent this would not be intrusive, and I think it
>> would work and it is simple: What about changing the shape of the
>> mouse pointer whenever the user placed it on an application? It could
>> be an X, similar to the X Window default pointer, for example. Or it
>> could be more elaborate, being a different shape *and* a different
>> color if it was actually the first time the user executed that
>> particular file.
>
> I prefer the OS to change the icon slightly on executable files (much
> like many UNIX users change their directory listing colors to show
> executable files in a different color.) The reasons are fairly minor:
>
> a) Changing the cursor means the OS has to continually examine files you
> mouse over. This requires file/processor usage just when mousing across
> the desktop to go to the dock or another window. Changing the icon only
> requires file/processor usage when the file is created on disk, not
> every time it's moused over.
>
> b) slightly less minor -- you have to put your mouse on a file before
> finding out if it's executable or not. The modified icon method visibly
> changes the icon which can be checked quickly, without having to move
> the mouse to the icon first.
>
> [I don't think the cursor idea is perfect, but I don't think changing icons is
> likely to make much difference. After all, icons can be faked easily, which
> isn't true of the cursor. And as much as it is processor time, for all Aqua is
> doing, changing a cursor seems minor. -Adam]

All of this is assuming of course that the trojan is trying to hide the fact
that it's an application.

This of course is the silly way to do it. Why hide the file type. It's FAR
more efficient to masquerade as an application that does some silly thing
that people want, and use that to hide the true purpose of your application.

Face it...if you ask a mac user to authenticate during the install process,
they will. 99 on't even care why. Apple has trained us to blindly do this.
So, with almost no work, you can get an administrator password and once you
have that, you've rooted the box. Not that you really need to. You can add
custom startup items in /Library/StartupItems without needing to be root,
and they run as root.

As long as people just authenticate without questioning, none of this change
the cursor stuff is going to work at all.

john

--
John C. Welch Writer/Analyst
Bynkii.com Mac and other opinions
jwelchbynkii.com

On 4/27/2004 6:43 PM, "Kevin van Haaren" <kevinvanhaaren.net> wrote:
> [I don't think the cursor idea is perfect, but I don't think changing icons is
> likely to make much difference. After all, icons can be faked easily, which
> isn't true of the cursor. And as much as it is processor time, for all Aqua is
> doing, changing a cursor seems minor. -Adam]

If the "change the icon" approach was implemented as a mask -- which is
probably how it would have to be done anyway -- pasting a custom icon
wouldn't affect the "application" designation, as the mask would be part of
the file's appearance no matter which icon was being used. Even better,
since such an indication would be implemented at the local/OS level, it
wouldn't be as easily circumvented by virus/trojan writers.

I've long thought that operating systems -- Mac or otherwise -- should
visually indicate which files are executable; such a feature has been a long
time coming, IMO.

----------------------------------
Get some Mac OS X Power Tools:
Second Edition available now!
<http://www.MacOSXPowerTools.com/>
----------------------------------

>> The modified icon method visibly changes the icon which can be
>> checked quickly, without having to move the mouse to the icon first.
>
> [I don't think the cursor idea is perfect, but I don't think changing
> icons is likely to make much difference. After all, icons can be faked
> easily, which isn't true of the cursor.

This does not apply to elements of the icon that are added by the
Finder, though.

In the case of aliases, e.g., changing the file's icon in the Info
window does not affect the little "alias arrow," of course. Also, I
can't imagine how to programmatically hide that arrow, either: it's
always on top of the icon, has a white border so the arrow is also
visible on fully-black icons, etc.

Consequently, it would be possible to make a non-app file appear as an
app by simply adding the "application indicator" to the original icon,
but I can't see how to make an app appear as a non-app file because
there is no (apparent) way to hide that indicator.

Jochen.

On 4/29/04 9:25 AM, "Dan Frakes" <DanFrakes.org> wrote:

> I've long thought that operating systems -- Mac or otherwise -- should
> visually indicate which files are executable; such a feature has been a long
> time coming, IMO.

Maybe, but then that assumes you're trying to hide the fact that a trojan is
an executable.

--
John C. Welch Writer/Analyst
Bynkii.com Mac and other opinions
jwelchbynkii.com

I've been lax in forwarding this; it's a response from the CEO of
Intego to my comments to their PR. He gave permission to republish it.

I've written a long and detailed response, but on reflection, I'm not
going to send it either here or to Intego, since I don't wish to drag
this unpleasant situation out further. I have more constructive
things to do with my time; should Intego perform such an
irresponsible action again in the future, I'll be ready.

cheers... -Adam

--- begin forwarded text

From: Laurent Marteau <lmarteauintego.com>
To: acetidbits.com
Subject: Re: FW: Q&A About MP3Concept Trojan Horse
Date: Thu, 22 Apr 2004 09:37:53 -0700

>>While the first versions of this Trojan horse that Intego has
>>isolated are benign, this technique opens the door to more serious
>>risks.
>
>What are these versions? Is there any specific file other than the
>proof of concept posted to comp.sys.mac.programmer? If so, what are
>their names? Trojans are not theoretical, they're very specific
>programs that have names and locations, and if you are concerned
>about protecting users, you should be saying exactly what files they
>should avoid.

First of all, the version of this Trojan horse we received is not the
same as the one found on comp.sys.mac.programmer. We received a file
called mysong.mp3, which is different from the virus.mp3 file that
has circulated on the Internet.

Intego has received other versions of similar exploits, including one
where the dot character was replaced by a similar looking character,
leading users to thing that the file had a legitimate extension (in
this case, it was .pdf). But how can we simply say what files they
should avoid, if the exploit is reproducible on any MP3 file? We
certainly can't tell them to avoid MP3 files in general. However, the
virus definitions we released for VirusBarrier protect against
applications masquerading as files with extensions.

We have not published security alerts for all of these exploits, but
for the MP3 exploit, we considered that there was a real danger.

One other note: the first reported Trojan horse for Mac OS X
(Mac.Simpsonsmm) was actually announced by Symantec
(http://securityresponse.symantec.com/avcenter/venc/data/mac.simpsonsmm.html),
and we have never found this in the wild. This announcement did not
lead to the same amount of criticism as our press release has.

>>We don't believe in waiting until the damage occurs, unlike some of
>>our competitors.
>
>Announcing has no relevance to waiting until the damage occurs, and
>in fact, your competitors were appropriately cautious about
>releasing this information to the public.

Perhaps because they weren't aware of it. We pointed out in our
second press release regarding this problem that we received the file
from someone who sent it to several antivirus vendors, along with
Apple. We reacted quickly, because we realized the extent of the
problem; it's very likely that the other companies ignored this
e-mail message, or didn't feel it was worth their time bothering with
it.

>>The Intego Virus Security Laboratory quickly discovered how to
>>block this Trojan horse and prevent it from running its code and as
>>part of our commitment to our users, it was only natural that we
>>release this in our latest virus definitions for Intego
>>VirusBarrier.
>
>It was totally reasonable to update your anti-virus product to
>protect against use of this technique. That's appropriate and no one
>would complain about that.
>
>>We initially hesitated about releasing this information, but
>>finally decided that it was our responsibility to alert users to
>>this security risk.
>
>Here's where I don't understand your logic. You didn't alert your
>users. You issued a general press release, thus ensuring that news
>of this technique for creating Trojans was widely disseminated, and
>thus vastly increasing the likelihood that it would happen for real.

This is a difficult issue - some people believe in security by
obfuscation, and others feel it is best to bring things out into the
open as soon as possible. In this case, we chose the latter approach.
We did alert our users indirectly; we issued an update to
VirusBarrier's virus definitions, which users obtain using the
NetUpdate preference pane. This update clearly specified that the new
virus definitions protected against this risk. Two days later, we
issued our first press release about it.

>Your initial hesitation was on the mark - I can't see any reason
>your company's behavior in releasing this information to the public
>(as opposed to updating your product, which is fine) wasn't entirely
>irresponsible and damaging to the Macintosh community.

We issued a press release because this is what software publishers
do. They never send e-mails to their customers when new viruses
appear; they update their virus definitions and issue press releases
or security alerts, as we will do in the future. You certainly cannot
criticize an antivirus publisher for reacting immediately to a
potential danger. If you look at the web sites of other antivirus
vendors, you'll see - at least for Windows - dozens of similar press
releases.

>If you believe you have a security concern with the operating
>system, a rational approach that wouldn't have any taint of
>self-promotion or worry about inappropriate publication of
>information would be to make sure it was reported to the correct
>channels at the vendor, and, if you felt the vendor wasn't being
>sufficiently responsive, to report the exploit to an independent
>security organization like CERT for verification and publication.

This is like criticizing a shoemaker for repairing shoes. Our job,
and our duty, is first and foremost to protect our users. This is why
they have purchased our antivirus software. We have tens of thousands
of users of our VirusBarrier program, and these users expect us to
act quickly. When viruses are discovered, other publishers do not
contact CERT first, but rather update their virus definitions and
issue security alerts.

We are certainly not happy that this weakness has appeared and that
it affects Mac OS. Intego is in no way trying to undermine the
Macintosh platform; we are specialized in Macintosh software and our
long-term objectives are to provide efficient products that thwart
all security risks. We love the Macintosh, and we strive to provide
users with solutions that help them user their Macs better and more
safely.

In the end, no matter what you may think of our approach, the
publicity this has generated has done a great deal of good for Mac OS
X. Instead of blindly assuming that the Mac is impervious to security
threats - and Apple's regular security updates show that this is not
the case - it's important to be aware that other risks may arise. We
still maintain, as we said in our first press release, that the
current version of this Trojan horse is benign, but that its
principle is potentially dangerous.

If we had this to do over again, the only thing we would have changed
was provide more information in our first press release. As you saw
in our second press release, we gave detailed information about how
this Trojan horse functions, which calmed many people who thought it
was simply a case of a custom icon being pasted on an application. In
the future, we will be much more careful and provide as much
information as we can.

Regards,

Laurent

--- end forwarded text

--
iPhoto 4 Visual QuickStart Guide now out! http://iphoto.tidbits.com/
Take Control of your Mac! Visit: http://www.tidbits.com/takecontrol/
_____________________________________________________________________
Adam C. Engst: I publish TidBITS, write books, and make sure the
acetidbits.com right people know each other in the Mac industry.
Me: http://www.tidbits.com/adam/ TidBITS: http://www.tidbits.com/

On 5/7/2004 8:52, "Adam C. Engst" <acetidbits.com> wrote:

> We issued a press release because this is what software publishers
> do. They never send e-mails to their customers when new viruses
> appear; they update their virus definitions and issue press releases
> or security alerts, as we will do in the future.

Really. And what are these messages we get from Sophos, which are sent
along to automation which causes us to go out and retrieve their latest
virus "IDE" files for our servers? (The automation installs the new IDE set
and does the appropriate restart.)

  --John

At 12:43 PM -0700 5/10/04, John W. Baxter wrote:
>
>On 5/7/2004 8:52, "Adam C. Engst" <acetidbits.com> wrote:
>
>> We issued a press release because this is what software publishers
>> do. They never send e-mails to their customers when new viruses
>> appear; they update their virus definitions and issue press releases
>> or security alerts, as we will do in the future.
>
>Really. And what are these messages we get from Sophos, which are sent
>along to automation which causes us to go out and retrieve their latest
>virus "IDE" files for our servers? (The automation installs the new IDE set
>and does the appropriate restart.)
>
> --John

Not to mention Authentium (formerly known as Command Antivirus)
<http://www.authentium.com/> which allows you to sign up for email
notification by email list, which I have been subscribed to for years.

--
William Ansley