Prev: Compressing huge files
Next: Can't delete files
From: Gregory Weston on 3 Jul 2008 00:28
In article <megadethguy-5BE652.20460202072008(a)newsgroups.comcast.net>,
Megadave <megadethguy(a)invalidgmail.domaincom> wrote:

> When 10.5 came out there was a great deal of controversy and problems
> with the firewall (mostly because it was a black box). What is the
> current level of confidence in it...? I'm thinking about moving back to
> it and turning IPFW back off...

Confidence in the firewall was never a problem. The controversy was over
the fact that when the firewall was activated in a certain mode,
software that exhibited either of two particular unsupported behaviors
stopped working. One of those behaviors has been essentially off the
table for serious application developers since the advent of the Mac and
the other has been unreliable since the release of Mac OS X.

For reference the two behaviors in question are:

1. An application that attempts to write back to itself. There are so
many circumstances under which this fails outright in the last 24+ years
it's downright pathetic that any vendor was shipping software that did
this last October. This has problems with the firewall because Apple's
security subsystem detects that the application has "changed" in some
way and assumes that there's a reasonable chance it has been tampered
with for nefarious purposes. One could argue that statistically the
likelihood is low, but again: the reality is that this behavior was
*never* considered legitimate or reliable in the history of the platform.

2. An application attempts to protect the user from running copies of
itself which have been tampered with by performing some sort of checksum
calculation on itself and refusing to run if the result doesn't match an
expected value. Essentially it's trying to do what the firewall does in
case 1, but it does so badly. This fails if the programmer is lazy about
checksumming and includes in the sum elements over which they have
neither control nor a guarantee of constancy. All versions of Mac OS X
have had the potential to silently edit certain segments of executable
files, so this hasn't been a safe course of action in nearly a decade.

Software that fails in the presence of the Leopard firewall because it
exhibits one of those behaviors is broken and should be reported to the
developer.

--
"Harry?" Ron's voice was a mere whisper. "Do you smell something ... burning?"
- Harry Potter and the Odor of the Phoenix
From: Barry Margolin on 3 Jul 2008 00:34
In article <uce-2BF835.00281903072008(a)newsclstr03.news.prodigy.net>,
Gregory Weston <uce(a)splook.com> wrote:

> In article <megadethguy-5BE652.20460202072008(a)newsgroups.comcast.net>,
> Megadave <megadethguy(a)invalidgmail.domaincom> wrote:
>
> > When 10.5 came out there was a great deal of controversy and problems
> > with the firewall (mostly because it was a black box). What is the
> > current level of confidence in it...? I'm thinking about moving back to
> > it and turning IPFW back off...
>
> Confidence in the firewall was never a problem. The controversy was over
> the fact that when the firewall was activated in a certain mode,
> software that exhibited either of two particular unsupported behaviors
> stopped working. One of those behaviors has been essentially off the
> table for serious application developers since the advent of the Mac and
> the other has been unreliable since the release of Mac OS X.
>
> For reference the two behaviors in question are:
>
> 1. An application that attempts to write back to itself. There are so
> many circumstances under which this fails outright in the last 24+ years
> it's downright pathetic that any vendor was shipping software that did
> this last October. This has problems with the firewall because Apple's
> security subsystem detects that the application has "changed" in some
> way and assumes that there's a reasonable chance it has been tampered
> with for nefarious purposes. One could argue that statistically the
> likelihood is low, but again: the reality is that this behavior was
> *never* considered legitimate or reliable in the history of the platform.
>
> 2. An application attempts to protect the user from running copies of
> itself which have been tampered with by performing some sort of checksum
> calculation on itself and refusing to run if the result doesn't match an
> expected value. Essentially it's trying to do what the firewall does in
> case 1, but it does so badly. This fails if the programmer is lazy about
> checksumming and includes in the sum elements over which they have
> neither control nor a guarantee of constancy. All versions of Mac OS X
> have had the potential to silently edit certain segments of executable
> files, so this hasn't been a safe course of action in nearly a decade.
>
> Software that fails in the presence of the Leopard firewall because it
> exhibits one of those behaviors is broken and should be reported to the
> developer.

What do either of these behaviors have to do with the firewall? The
firewall blocks certain network packets, and has nothing to do with how
applications deal with the local filesystem.

--
Barry Margolin, barmar(a)alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
From: Gregory Weston on 3 Jul 2008 01:59
In article <barmar-D8F7ED.00340903072008(a)newsgroups.comcast.net>,
Barry Margolin <barmar(a)alum.mit.edu> wrote:

> In article <uce-2BF835.00281903072008(a)newsclstr03.news.prodigy.net>,
> Gregory Weston <uce(a)splook.com> wrote:
>
> > In article <megadethguy-5BE652.20460202072008(a)newsgroups.comcast.net>,
> > Megadave <megadethguy(a)invalidgmail.domaincom> wrote:
> >
> > > When 10.5 came out there was a great deal of controversy and problems
> > > with the firewall (mostly because it was a black box). What is the
> > > current level of confidence in it...? I'm thinking about moving back to
> > > it and turning IPFW back off...
> >
> > Confidence in the firewall was never a problem. The controversy was over
> > the fact that when the firewall was activated in a certain mode,
> > software that exhibited either of two particular unsupported behaviors
> > stopped working. One of those behaviors has been essentially off the
> > table for serious application developers since the advent of the Mac and
> > the other has been unreliable since the release of Mac OS X.
> >
> > For reference the two behaviors in question are:
> >
> > 1. An application that attempts to write back to itself. There are so
> > many circumstances under which this fails outright in the last 24+ years
> > it's downright pathetic that any vendor was shipping software that did
> > this last October. This has problems with the firewall because Apple's
> > security subsystem detects that the application has "changed" in some
> > way and assumes that there's a reasonable chance it has been tampered
> > with for nefarious purposes. One could argue that statistically the
> > likelihood is low, but again: the reality is that this behavior was
> > *never* considered legitimate or reliable in the history of the platform.
> >
> > 2. An application attempts to protect the user from running copies of
> > itself which have been tampered with by performing some sort of checksum
> > calculation on itself and refusing to run if the result doesn't match an
> > expected value. Essentially it's trying to do what the firewall does in
> > case 1, but it does so badly. This fails if the programmer is lazy about
> > checksumming and includes in the sum elements over which they have
> > neither control nor a guarantee of constancy. All versions of Mac OS X
> > have had the potential to silently edit certain segments of executable
> > files, so this hasn't been a safe course of action in nearly a decade.
> >
> > Software that fails in the presence of the Leopard firewall because it
> > exhibits one of those behaviors is broken and should be reported to the
> > developer.
>
> What do either of these behaviors have to do with the firewall? The
> firewall blocks certain network packets, and has nothing to do with how
> applications deal with the local filesystem.

The Leopard firewall has a mode of operation that allows or denies
connections based on the application that is attempting to communicate.
The firewall (along with other security-related components of Leopard)
identifies the apps based on a fairly large and complex byte sequence
that can't trivially be faked or edited (unlike names, creator codes,
process signatures, etc) but *can* be carried forward from one version
to the next of a given program. With the release of Leopard, Apple
recommended that developers include these signature blocks in their
shipping products but they will generate them on the fly if necessary
(for legacy software as well as developers who haven't come up to speed
on new practices yet). The failures occur when Apple generates the
signature block.

In the first case above, when the application changes itself the
Apple-generated signature block to no longer match the app as it exists,
so Apple's security code rejects it as tainted.

In the second case, the app's built-in checksum validator gets tripped
up by the data that it didn't know about but really shouldn't be looking
at any way.

--
"Harry?" Ron's voice was a mere whisper. "Do you smell something ... burning?"
- Harry Potter and the Odor of the Phoenix
 | 
Pages: 1
Prev: Compressing huge files
Next: Can't delete files