Focus on Apple
Apple releases Mac OS X v10.5.1 with Application Firewall security updates Nov 15 2007 07:11PM
Todd Woodward (todd_woodward symantec com) (1 replies)
Application Firewall security updates Nov 15 2007 08:08PM
Radoslav Dejanoviæ (radoslav dejanovic opsus hr) (4 replies)
Re: Application Firewall security updates Nov 21 2007 03:00PM
Dave Piscitello (dave corecom com) (2 replies)
Re: Application Firewall security updates Nov 21 2007 09:27PM
Ansgar -59cobalt- Wiechers (bugtraq planetcobalt net) (3 replies)
Re: Application Firewall security updates Nov 22 2007 06:35PM
Derek Chesterfield (dez mac com)
Re: Application Firewall security updates Nov 22 2007 04:28PM
Bruce Carter (bcarter nd edu)
RE: Application Firewall security updates Nov 21 2007 10:43PM
Todd Woodward (todd_woodward symantec com)
Re: Application Firewall security updates Nov 21 2007 09:02PM
Chris Adams (chris improbable org)
Re: Application Firewall security updates Nov 16 2007 03:58AM
Mike Savory (mike_lists nzbox com)
RE: Application Firewall security updates Nov 15 2007 09:55PM
Todd Woodward (todd_woodward symantec com)
Re: Application Firewall security updates Nov 15 2007 09:51PM
Dave Schroeder (das doit wisc edu) (3 replies)
Re: Application Firewall security updates Nov 15 2007 11:36PM
Mark Senior (senatorfrog gmail com) (3 replies)
Re: Application Firewall security updates Nov 17 2007 02:54PM
Chris Pepper (pepper reppep com) (1 replies)
Re: Application Firewall security updates Nov 19 2007 12:59PM
Sandor Szücs (sszuecs zedat fu-berlin de)
Re: Application Firewall security updates Nov 16 2007 11:03AM
Radoslav Dejanoviæ (radoslav dejanovic opsus hr) (2 replies)
Re: Application Firewall security updates Nov 16 2007 05:30PM
Mark Senior (senatorfrog gmail com)
On Nov 16, 2007 4:03 AM, Radoslav Dejanoviæ wrote:

> Mark Senior wrote:
> >
> > But, they've missed the big possibility for improvement here - they
> > have an application-aware firewall - why on earth would they not apply
> > it to outbound connections? No interesting malware requires inbound
> > connections anymore; it's already written to get past home routers
> > that allow all outbound and deny all inbound connections. Ah well.
> >
>
> That's an interesting point, but it's got its own set of problems. How
> would you know what all the different applications need to communicate
> with? You should be aware that mail reader has to have access to POP
> (and|or) IMAP and SMTP, maybe even newsgroups, and you have to know
> that for every single application out there, if you do not want to
> bother user with questions.
>

Indeed - Apple applications could come with predefined filters, just as a
few of them already come with prebuilt sandbox profiles - as you say, we
know that Mail.app will need to make outbound connections to POP3[S],
IMAP4[S], SMTP[S], NNTP (is there an NNTPS protocol?), and that should be
about it.

A downloaded program advertised as a single-player pinball game, however,
shouldn't need outbound connections, at all. If it really does, then the
developer had better actually write a line or two of documentation... And
if a program the user didn't even realize he was running, starts to asking
for permission to connect to an IRC server in China, you've caught the
malware.

Now, I was thinking a bit more about this, and Apple would probably have to
develop a serious capabilities framework for this to not be trivially
bypassable (maybe the new sandbox framework would actually be capable of
it). Otherwise, an application that is not trusted to make outgoing
connections, could simply shell out to one that is - for example, a piece of
malware could easily fork and exec the (Apple-provided, signed-binary)
netcat, and just pass traffic through pipes or Unix domain sockets.

The only way to make this really work, I think, would be to have the ability
to make network connections tied to the process object in the kernel, which
would have to be inherited all the way back from PID 1. Once a process
without the right to make network connections is executed, it loses that
ability, and cannot pass it on to any processes it spawns, regardless of
whether the executable in question has the ability to inherit such
permissions.

This still raises the challenge of processes inserting threads into other,
networking-allowed, processes. Some Windows malware gets around host based
application-aware firewalls in just this way, by inserting a DLL and a
thread into a process that is likely to have network permission, like
Internet Explorer. Either antivirus software, or the firewall itself, then
has to be on the lookout for that sort of malware-like behaviour. This
would require another element of the capabilities framework - the ability to
invoke create-thread type system calls on other processes, must never flow
from a networking-denied process, to a networking-allowed process.

And I'm sure I've missed about half a dozen other ways to bypass networking
restrictions that a determined malware writer could take. Even so - even
without watching for evasion techniques, the XP application firewall can
catch most current malware.

Fun stuff, isn't it? Cheers,
Mark
<br><br>
<div class="gmail_quote">On Nov 16, 2007 4:03 AM, Radoslav Dejanoviæ wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div class="Ih2E3d">Mark Senior wrote:<br>><br>> But, they've missed the big possibility for improvement here - they<br>> have an application-aware firewall - why on earth would they not apply<br>> it to outbound connections?  No interesting malware requires inbound
<br>> connections anymore; it's already written to get past home routers<br>> that allow all outbound and deny all inbound connections.  Ah well.<br>><br><br></div>That's an interesting point, but it's got its own set of problems. How
<br>would you know what all the different applications need to communicate<br>with? You should be aware that mail reader has to have access to POP<br>(and|or)  IMAP and SMTP, maybe even newsgroups, and you have to know<br>
that for every single application out there, if you do not want to<br>bother user with questions.<br></blockquote></div>
<div> </div>
<div>Indeed - Apple applications could come with predefined filters, just as a few of them already come with prebuilt sandbox profiles - as you say, we know that Mail.app will need to make outbound connections to POP3[S], IMAP4[S], SMTP[S], NNTP (is there an NNTPS protocol?), and that should be about it.
</div>
<div> </div>
<div>A downloaded program advertised as a single-player pinball game, however, shouldn't need outbound connections, at all.  If it really does, then the developer had better actually write a line or two of documentation...  And if a program the user didn't even realize he was running, starts to asking for permission to connect to an IRC server in China, you've caught the malware.
</div>
<div> </div>
<div>Now, I was thinking a bit more about this, and Apple would probably have to develop a serious capabilities framework for this to not be trivially bypassable (maybe the new sandbox framework would actually be capable of it).  Otherwise, an application that is not trusted to make outgoing connections, could simply shell out to one that is - for example, a piece of malware could easily fork and exec the (Apple-provided, signed-binary) netcat, and just pass traffic through pipes or Unix domain sockets.
</div>
<div> </div>
<div>The only way to make this really work, I think, would be to have the ability to make network connections tied to the process object in the kernel, which would have to be inherited all the way back from PID 1.  Once a process without the right to make network connections is executed, it loses that ability, and cannot pass it on to any processes it spawns, regardless of whether the executable in question has the ability to inherit such permissions.
</div>
<div> </div>
<div>This still raises the challenge of processes inserting threads into other, networking-allowed, processes.  Some Windows malware gets around host based application-aware firewalls in just this way, by inserting a DLL and a thread into a process that is likely to have network permission, like Internet Explorer.  Either antivirus software, or the firewall itself, then has to be on the lookout for that sort of malware-like behaviour.  This would require another element of the capabilities framework - the ability to invoke create-thread type system calls on other processes, must never flow from a networking-denied process, to a networking-allowed process.
</div>
<div> </div>
<div>And I'm sure I've missed about half a dozen other ways to bypass networking restrictions that a determined malware writer could take.  Even so - even without watching for evasion techniques, the XP application firewall can catch most current malware.
</div>
<div> </div>
<div>Fun stuff, isn't it?  Cheers,</div>
<div>Mark</div>

[ reply ]
Re: Application Firewall security updates Nov 16 2007 04:34PM
Derek Chesterfield (dez mac com) (1 replies)
Re: Application Firewall security updates Nov 17 2007 12:30AM
Mark Senior (senatorfrog gmail com)
Re: Application Firewall security updates Nov 16 2007 04:47AM
Derek Chesterfield (dez mac com) (2 replies)
Re: Application Firewall security updates Nov 16 2007 04:08PM
Scott Russell (ScottRussell nd edu)
Fwd: Application Firewall security updates Nov 16 2007 04:55AM
Derek Chesterfield (dez mac com)
Re: Application Firewall security updates Nov 15 2007 10:08PM
Radoslav Dejanoviæ (radoslav dejanovic opsus hr)
Re: Application Firewall security updates Nov 15 2007 10:05PM
Dave Schroeder (das doit wisc edu)


 

Privacy Statement
Copyright 2010, SecurityFocus