Mac malware checker?

On 5/3/06 at 9:42 AM, johnbaxterlistsmac.com wrote:

>On May 3, 2006, at 7:34 AM, Sander Tekelenburg wrote:

>I think there is some reality in this part of Intel fear. The
>underlying architecture seems to make it easier on Intel than on
>PPC- as-used-by-Apple (and others) to put together buffer overflow
>situations which directly "hit" the return address of the current
>function (or some parent), thus redirecting execution.

Yes, this is the type of reasoning some are using to conclude MacIntels are likely to be more susceptible to viruses. But it is fallacious reasoning. The only thing an Intel processor does that a PPC processor can't do relative to existing Windows malware is that code can potentially run as is on a MacIntel while there is no possibility of it running on a PPC processor as is. And potentially is correct since any code that requires some aspect of the Windows operating system will not run as is on a MacIntel running OS X.

Such things as buffer overflow are totally independent of hardware. They are strictly a software issue. If the software is written correctly, a buffer overflow cannot occur. If you assume the source code for MacIntel's is identical to that for the older PPC based machines and the compiler introduces no errors, the susceptibility of a MacIntel to malware will be identical to that of a PPC based Mac. But the assumption of identical code and no compiler errors is likely to be a bit strong.

More likely some portion of the code base has been modified to some degree to take advantage of characteristics of the Intel processors. Any change has the potential to change the susceptibility of the system to malware. But this is a software issue not a hardware issue.

"5] The story mentions lots of "security experts" without naming them. That means that you, the reader, cannot verify whether these security experts actually are security experts. They could just as easily be anti-virus industry marketeers, trying to lure people into buying their product"

They could, indeed. Threre's a lot of FUD floating around out there masquerading as security analysis.

Case in point: the much-cited "quiz" by McAfee which purports to demonstrate that "97%" of those who took the quiz were taken in by at least one malware site. What they *don't* mention is that the quiz (which I took; you can too at http://www.siteadvisor.com/quizzes/spyware_0306.html) consisted entirely of screen shots of various web sites. Based only on these, you were expected to pick out which ones were "drive by downloaders", pushers of malware and the like.

Some are obvious but with others it's virtually impossible to determine that (for example) one site does drive-by ActiveX downloads without seeing it live in a properly-configured browser. Clearly, the intent is to convince us all that we can't tell sh*t from shinola on the web and need to buy McAfee's products to protect us. It's a marketing tool, but the trade press and even the mainstream media have treated it as though it were a serious study.

No wonder non-techies are confused! -- Chuck Lavazzi Arts Producer - KDHX-FM http://www.kdhx.org - http://www.stageleft.org

Sander Tekelenburg wrote:

>>>I'm not at all keeping track of it, but my impression was that
>there is hardly any Linux malware out there.

Could that be because our malicious hackers are all using Linux to
manfacture anti-Gates malware?

Paul

At 21:32 05/03/06 -0700, Bill Rowe wrote:
>Such things as buffer overflow are totally independent of hardware. They
>are strictly a software issue.

This may be true for Intel and PPC CPUs, but is certainly not true in
general. There have been plenty of computers, including some still on the
market today despite the choking out of those that don't hew to today's
popular designs, where the hardware (or at least the microcode) protects
against buffer overflow along with all other kinds of out-of-bounds access.

Edward
Art works by Melynda Reid: http://paleo.org

On May 3, 2006, at 9:32 PM, Sander Tekelenburg wrote:

> At 09:42 -0700 UTC, on 2006-05-03, johnbaxterlistsmac.com wrote:
>
> [...]
>
> [Mac more of a target due to switch to Intel]
>
>> I think there is some reality in this part of Intel fear. The
>> underlying architecture seems to make it easier on Intel than on PPC-
>> as-used-by-Apple (and others) to put together buffer overflow
>> situations which directly "hit" the return address of the current
>> function (or some parent), thus redirecting execution.
>
> OK, that sounds legitimate to my ears (ignoring that I'm not
> qualified to
> judge this).
>
> But then, wouldn't you expect all those Linux PCs running on Intel
> CPUs to be
> targeted? I'm not at all keeping track of it, but my impression was
> that
> there is hardly any Linux malware out there.

The Unix folks learned about buffer overruns years ago, and most (but
not all, sadly) are gone. The Linux folks learned from their Unix
predecessors and didn't add *many* buffer overflows to what they
inherited. The learning wasn't complete (it never is).

The Microsoft folks somehow failed to pick up the lessons from Unix--
some think the frantic pursuit of feature check boxes got in the
way. Also, open source (a phrase which didn't quite apply to Unix
early-on, doesn't apply to what Microsoft creates except in special
cases, and partly applies to Apple allows many eyes to view the code
and see the lurking problems). Another early Microsoft issue was
that the routine interconnection of machines was simply not imagined.

(I did phone support for Userland for a while in the early 1990s. I
had one contact with a major long distance phone company--I couldn't
send him email at work nor could he download fixes at work, since his
office was in a building where data connections to and from the
outside were totally banned. So I had to read some fairly long bits
of code to him over the phone.)

It continues to astound me that so many mission-critical machines are
routinely connected to the Internet (Internet virus problems SHOULD
NOT shut down major regional railroads, as has happened).

One view of the modern world is that a company (of the Apple,
Microsoft, Oracle, etc type) needs a security czar, whose people
report to him or her problems they see in security audits, and who
has power to block software shipment if deemed appropriate (with the
over rule being at the Bill Gates/Steve Balmer or Steve Jobs level,
since the decision is "is it worth risking serious damage to the
company to put this out in this form because of some overriding
consideration). Microsoft is improving in this regard (as seen in
the slippage of Longwait to after this year's holiday sales season).

   --John

Paul Atroshenko wrote:
> Sander Tekelenburg wrote:
>> I'm not at all keeping track of it, but my impression was that
>> there is hardly any Linux malware out there.
>
> Could that be because our malicious hackers are all using Linux to
> manfacture anti-Gates malware?

Why yes:

http://shelleytherepublican.com/2006/04/linux-european-threat-to-our-computers.html


   Ben Rubinstein | Email: benrcogapp.com
   Cognitive Applications Ltd | Phone: +44 (0)1273-821600
   http://www.cogapp.com | Fax : +44 (0)1273-728866

On May 3, 2006, at 9:32 PM, Bill Rowe wrote:

> Such things as buffer overflow are totally independent of hardware.
> They are strictly a software issue. If the software is written
> correctly, a buffer overflow cannot occur. If you assume the source
> code for MacIntel's is identical to that for the older PPC based
> machines and the compiler introduces no errors, the susceptibility
> of a MacIntel to malware will be identical to that of a PPC based
> Mac. But the assumption of identical code and no compiler errors is
> likely to be a bit strong.

No, the architecture is significant. Which is not to say that things
on the Mac will automatically be like things in Windows because of
the move to Intel: they won't.

Buffers can be overrun on either Intel or PPC. However, I *think* it
is much more common for the buffer to live on the execution stack on
Intel than on PPC, because of coding habits found in the two worlds.
(A buffer *can* be put on execution stack in either case, and C code
which began life on Intel is probably more likely to allocate a
buffer as an automatic variable rather than a pointer into heap, and
stay that way during the port.) Code which started in PPC and moved
to Intel is unlikely to have the uses of heap replaced by uses of
stack along the way.

The result of a buffer overflow depends heavily on the venue of the
buffer (it is bad in some way in any case, although small ones can be
controlled by compiler/library combinations which over-allocate, seed
the extra space, and look for overruns as the buffer is released.
The machine-takeover overruns aren't small ones (forgetting to allow
for the newline and NULL one is going to append to the n-byte string
in C), but large ones which try to overlay the function return
address with a new one pointing further into the overrun. (And
indeed, if code won't execute in that neighborhood, it certainly helps.)

A new problem in all worlds is that "n characters" is no longer equal
to "n bytes" in the general case. So a buffer which didn't overflow
in US ASCII (or the various non-standardized extensions into the top-
bit-set half of the character-per-byte world) can now overflow when
it contains the same number of (wider) characters. Those buffers
haven't yet all been expanded or moved to heap from stack.

Of course, "proper" machines had 36-bit words with 6-bit characters
fit into them. And a big 36-bit machine had 32K of them (water
cooled walk through monsters in some cases)--and 6 figure annual
lease costs. I diagnosed what was effectively similar to a buffer
overflow issue on one of those: student project was adding
extensions to a provided assembler. One of the suggested extensions
was to sort the symbol table (held in memory) between passes one and
two of the assembler. One student's attempt crashed badly at the
start of pass 2. It turned out that he had sorted memory the right
number of words from the start of the symbol table. But the wrong
direction. IBM 704 code does not execute well after it has been
sorted, and it happened to be code needed for pass 2 which got
sorted. (The instructor, later a key guy in Multics, was willing to
call the problem a machine error.)

Or 60-bit words, with 6 bit characters or mixes of 6 and 12 bit
characters (CDC).

   --John

On 5/4/06 at 11:47 AM, edwardpaleo.org (Edward Reid) wrote:

>At 21:32 05/03/06 -0700, Bill Rowe wrote:
>>Such things as buffer overflow are totally independent of hardware.
>>They are strictly a software issue.

>This may be true for Intel and PPC CPUs, but is certainly not true
>in general. There have been plenty of computers, including some
>still on the market today despite the choking out of those that
>don't hew to today's popular designs, where the hardware (or at
>least the microcode) protects against buffer overflow along with all
>other kinds of out-of-bounds access.

Arguing microcode in ROM is the exception to the general rule grants special status to code stored in ROM. Yes, these bits cannot be further changed by other hardware or software without permanent damage to the machine. But these bits still are a physical implementation of software.

Certainly any system that uses microcode to guard against buffer overrun other other issues do not become more or less susceptible to malware when the CPU is changed. The worst that can occur is additional errors can be made when translating the microcode to a form required by the architecture of the new CPU. And that may or may not increase susceptibility of a system to malware.

At 8:54 PM -0700 5/4/06, johnbaxterlistsmac.com wrote:
>is much more common for the buffer to live on the execution stack on
>Intel than on PPC, because of coding habits found in the two worlds.

Coding habits are not based on CPU architecture; they depend on the
design of the APIs, documentation, sample code, developer experience,
etc. Once the developer makes a choice between stack and heap, the
location of the buffer will be the same regardless of what the target
CPU is.

--
Larry Rosenstein
lrosensteincatsincharge.com

On 5/4/06 at 8:54 PM, johnbaxterlistsmac.com wrote:

>On May 3, 2006, at 9:32 PM, Bill Rowe wrote:
>
>>Such things as buffer overflow are totally independent of hardware.
>>They are strictly a software issue. If the software is written
>>correctly, a buffer overflow cannot occur. If you assume the source
>>code for MacIntel's is identical to that for the older PPC based
>>machines and the compiler introduces no errors, the susceptibility
>>of a MacIntel to malware will be identical to that of a PPC based
>>Mac. But the assumption of identical code and no compiler errors is
>>likely to be a bit strong.

>No, the architecture is significant. Which is not to say that
>things on the Mac will automatically be like things in Windows
>because of the move to Intel: they won't.

Yes, the architecture is significant. Different architecture will mean different coding. Hence my last comment above that the assumption of identical code and no complier errors being a bit strong, meaning not likely to be valid in the real world. But a buffer overflow is a software coding issue, not a hardware issue.

At 20:54 05/04/06 -0700, Bill Rowe wrote:
>Arguing microcode in ROM is the exception to the general rule grants
>special status to code stored in ROM. Yes, these bits cannot be further
>changed by other hardware or software without permanent damage to the
>machine. But these bits still are a physical implementation of software.

Eppur si muove.

I can safely say that Burroughs/Unisys MCP systems (the B-6700 and its
successors) in production have never suffered from a buffer overflow,
either due to programming error or malice. You simply can't get there from
here. I'm talking many tens of thousands of systems over the past 35 years.
Although the software environment is part of the system of protection, the
low level, hard protection is done at the ISA level.

This kind of protection works, and works with a lot less anguish and
anxiety than protection in user-level software. And it's just there,
immovable, in the system as delivered to the customer. It doesn't depend on
what programming practices or packages you use. It's not something you have
to implement; it's something you cannot circumvent.

Edward
Art works by Melynda Reid: http://paleo.org

But then, wouldn't you expect all those Linux PCs running on Intel CPUs to be targeted? I'm not at all keeping track of it, but my impression was that there is hardly any Linux malware out there.

That's probably the situation because in order to make 'good' use of a buffer overflow, you will ultimately want to access the underlying OS via its API's. And there are simply many more individuals who are well versed in the Win32 API than there are with regards to the Linux API/traps. (Another point might be that because of the many 'flavors' of Linux in existance it is much more difficult to create intruding code that consistently affects each version.)

In theory Apple's use of Intel CPU's might make it easier for existing malware creators who wish to target Mac OS X, because these guys already know how to interpret the majority of the opcodes by heart or at least have lots of CPU-specific tools, like disassemblers and emulators, at their convenience. There's also more documentation in books and on the web about the Intel CPU than there's about the PPC. Injected code will almost always be written in assembler, at which time a good working knowledge of the CPU at hand comes in very handy. But as the Linux case seems to prove, intimate knowledge of the OS might be the more important aspect in the end.

One characteristic of the Intel processors might even make Macs _less_ vulnerable to buffer overflow attacks though: they have built-in hardware protection against running code from data segments, the so-called 'Execute Disable Bit', which even the Core Solo CPU employs.

http://www.intel.com/products/processor_number/index_sitelet_view2.htm

However, does anybody know if Apple has this feature turned on by default in Mac OS X? Or is there a Control Panel setting for it as there is in Windows XP? (As you probably guessed already, I still make do with a G5 ;)

Vincent van 't Zand Software Engineer

On May 8, 2006, at 3:43 AM, Edward Reid wrote:
> I can safely say that Burroughs/Unisys MCP systems (the B-6700 and its
> successors) in production have never suffered from a buffer overflow,
> either due to programming error or malice. You simply can't get
> there from
> here. I'm talking many tens of thousands of systems over the past
> 35 years.
> Although the software environment is part of the system of
> protection, the
> low level, hard protection is done at the ISA level.
>
> This kind of protection works, and works with a lot less anguish and
> anxiety than protection in user-level software. And it's just there,
> immovable, in the system as delivered to the customer. It doesn't
> depend on
> what programming practices or packages you use. It's not something
> you have
> to implement; it's something you cannot circumvent.

Well, it definitely does depend on software, because this kind of
protection can't be done at the system level for the C programming
language (unfortunately). The language and its library specification
does not allow enough constraints to be applied to ensure this level
of safety. That is the underlying problem with Unix and Unix-like
systems. Until C, or at least its set of standard libraries, is
replaced with a more constrained language, the danger will remain.
Once a language is selected which allows such checking, it is
possible to select three paths: employ hardware support that supports
bounds checking, implement bounds checking in software (at a
performance cost), or run without bounds checking.

Geoff

On 5/10/06 14:13, "Geoffrey Odhner" <GeoffreyOdhner.net> wrote:

>> This kind of protection works, and works with a lot less anguish and
>> anxiety than protection in user-level software. And it's just there,
>> immovable, in the system as delivered to the customer. It doesn't
>> depend on
>> what programming practices or packages you use. It's not something
>> you have
>> to implement; it's something you cannot circumvent.
>
> Well, it definitely does depend on software, because this kind of
> protection can't be done at the system level for the C programming
> language (unfortunately). The language and its library specification
> does not allow enough constraints to be applied to ensure this level
> of safety. That is the underlying problem with Unix and Unix-like
> systems. Until C, or at least its set of standard libraries, is
> replaced with a more constrained language, the danger will remain.
> Once a language is selected which allows such checking, it is
> possible to select three paths: employ hardware support that supports
> bounds checking, implement bounds checking in software (at a
> performance cost), or run without bounds checking.

SUre it can, just depends on the OS. If you do C work on an AS/400, the OS
and the underlying SLIC make it impossible for your to affect anything else.

It all depends on how much work the OS vendor wants to do.

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

At 12:13 05/10/06 -0700, Geoffrey Odhner wrote:
>Well, it definitely does depend on software, because this kind of
>protection can't be done at the system level for the C programming
>language (unfortunately).

C runs on Unisys MCP systems and is not subject to code being overwritten
by buffer overflows.

It's true that for data, C is in the realm of FORTRAN common blocks, and a
buffer overflow (or other bounds violations) could destroy other data. But
this kind of overflow does not jeopardize system integrity, only
application data.

I'm no C expert, but AFAIK there is nothing in the C specs that requires
mixing of code and data.

Now, if your OS is written in C, taking advantage of all the insecurities
in the C specs, then you have a problem. But the problem is in having
chosen such a way of building a system. The issue was whether "the
hardware" (meaning the ISA) could protect against a certain kind of danger.
It can, but only if you choose a compatible method of building the OS.

(It was once said that FORTRAN was the world's most popular assembler
language. C has taken its place, both in popularity and because Fortran,
unlike C, has shed its assembler characteristics.)

Edward
Art works by Melynda Reid: http://paleo.org

On May 11, 2006, at 4:58 AM, Edward Reid wrote:
> C runs on Unisys MCP systems and is not subject to code being
> overwritten
> by buffer overflows.
>
> It's true that for data, C is in the realm of FORTRAN common
> blocks, and a
> buffer overflow (or other bounds violations) could destroy other
> data. But
> this kind of overflow does not jeopardize system integrity, only
> application data.

Yes, you can protect against buffer overruns overwriting code. When
you said Burroughs/Unisys MCP systems never suffered from a buffer
overflow, I read you as saying they never happened, rather than that
the systems blithely ignored them.

Geoff Odhner

At 10:14 05/11/06 -0700, Geoffrey Odhner wrote:
>Yes, you can protect against buffer overruns overwriting code. When
>you said Burroughs/Unisys MCP systems never suffered from a buffer
>overflow, I read you as saying they never happened, rather than that
>the systems blithely ignored them.

Depends on what you call a buffer. To me, a buffer is an area of memory
handed to an IO subsystem (including a network adaptor) to send or receive
data. In this sense, even C programs do not suffer buffer overflows on MCP
systems. But the real buffer will not be in the C heap, but a separate
array that's allocated in the native way, and the data will be moved into
the C heap later. So although a C program could wander off the ends of an
array, a network adaptor could not.

Again, the system is totally protected. Code is totally protected. And
since we are discussing what malware can do, that's the issue. Even C
programs cannot overwrite code, or execute data, on MCP systems, neither
intentionally nor accidentally.

Some programming languages, such as FORTRAN, COBOL, PL/I (in its day), and
C force the system to allow a program to access its data in ways which are
a danger to that program's data. But that's different from allowing
operations which endanger the system. C may be inherently insecure in terms
of handling data, but extending that insecurity to the system itself is a
choice made by the system designers, not a requirement of C.

So yes, there are various levels of protection and lots of semantic
variations. But the insecurities which allow malware to propagate do not
exist on MCP systems -- even though those systems can run C programs.

Edward
Art works by Melynda Reid: http://paleo.org

One characteristic of the Intel processors might even make Macs _less_ vulnerable to buffer overflow attacks though: they have built-in hardware protection against running code from data segments, the so-called 'Execute Disable Bit', which even the Core Solo CPU employs.

http://www.intel.com/products/processor_number/index_sitelet_view2.htm

However, does anybody know if Apple has this feature turned on by default in Mac OS X? Or is there a Control Panel setting for it as there is in Windows XP? (As you probably guessed already, I still make do with a G5 ;)

I have been searching for an answer to my own question and didn't find anything on Apple's sites, not even in the developer info.

Then, in a feature article of MacUser about possible new capabilities in Mac OS X 10.5 - Leopard, I read this:

"Most likely is that Apple will take advantage of one of the security features built into most of Intel's current range: Execute Disable Bit (EDB) functionality."

http://macuser.pcpro.co.uk/macuser/features/83379/leopard-mac-os-x-105/page4.html

That means Apple doesn't yet take advantage of EDB protection in 10.4, which is not too surprising, considering that turning this functionality on would probably cause some existing software to fail. I believe it is not too common a practice in the world of modern 3GL and 4GL programming languages, but there still might be Mac OS X software around that changes its own code during runtime by design. Those programs will have to be altered for correct operation under EDB protection.

The OS itself might possibly be the most affected by turning on the EDB. Any ideas about the number of programs that would stumble with EDB protection?

At 09:29 06/19/06 -0700, V.O.vantZand wrote:
>there still might be Mac OS X software around that changes its own code
>during runtime by design. Those programs will have to be altered for
>correct operation under EDB protection.

Old code would be PowerPC code, which isn't executed on the Intel CPU but
rather is treated as data. Self-modifying PowerPC code would still be
allowed to "execute". (I won't say that it will still "work", given the
very strong argument that self-modifying code doesn't work in the practical
sense.)

So only very new self-modifying code, designed specifically for the Intel
CPU, would be affected. One would hope that programmers writing such code
would be aware of the potential to disable that capability. Of course,
assuming appropriate knowledge on the part of software engineers has its
own pitfalls, but at least there's only a very short time frame in which
such usage could have arisen.

Edward
Art works by Melynda Reid: http://paleo.org

--On June 19, 2006 9:29:44 AM -0700 "V.O.vantZand"
<v.o.vantzandtudelft.nl> wrote:

>
> That means Apple doesn't yet take advantage of EDB protection in 10.4,
> which is not too surprising, considering that turning this functionality
> on would probably cause some existing software to fail.

Grrr. Apple should've turned this on on the switch when they shipped the
Intel Macs. Software needed to be recompiled to run natively anyway, and
this was the time to make developers adopt the practice.

My guess is a) there is something in the OS itself that needs this and has
been fixed in 10.5 or b) Rosetta needs it for running PPC applications.
Maybe both.

BTW, this setting in Windows XP usually causes a lot of problems. Mainly
because it is new to the scene and developers have had a long time to adopt
bad habits.