[ale] how can a firewalled PC POSSIBLY be attacked?

[Matthew]

Just cause you have a firewall, doesn't mean that nothing can beat it. Can
people still steal your car when you put on an alarm? Phil put a good
answer up though.


On Tue, Jan 22, 2013 at 9:15 PM, Phil Turmel <philip at turmel.org> wrote:

> On 01/22/2013 08:28 PM, Ron Frazier (ALE) wrote:
> > The discussion on vpn's and security at Emory prompted me to ask
> > this.  This was prompted by some statements in another thread that a
> > PC could be in danger if attached to unfiltered lan ports on Emory's
> > network.
> >
> > Assume you have a PC connected directly to the internet.  It doesn't
> > matter if it's linux, windows, mac, or android.  I'm speaking in
> > conceptual terms.  Assume the PC is not running any server type
> > programs, so it is not listening on any ports.  Assume no one is
> > browsing to potentially malicious web pages, or even any web pages.
> > The PC is just sitting there idling.  Assume the PC has firewall
> > software running.  The firewall's only job is to drop all packets
> > that are not part of a response to an inquiry that this PC has
> > issued.    I don't want to debate, at this point, the pros and cons
> > of dropping all packets or operating in stealth mode.
> >
> > My question is, conceptually speaking, how can this PC POSSIBLY be
> > vulnerable to any remote attack?  How could anything phase it?
>
> Because a software firewall is *software*, and it is part of a
> closed-source operating system that is opaque to audits.  Said operating
> system has a history of alternate paths in its kernel that permit
> various packet types to reach the OS in spite of the firewall.
>
> Third-party firewalls couldn't close the loopholes either, as the hooks
> offered by MS for their use saw packets only after the loopholes' hook.
>
> I don't remember all the details, but I believe bypasses that caused the
> most trouble were part of the remote procedure call subsystem.  I
> believe MS has since closed that one.  But there's no way to know what
> MS still has, not to mention any exploitable flaws that remain.
>
> > Then, how does the answer change depending on whether it is linux,
> > windows, mac, or android.
>
> Windows and MacOS have network protocol stacks with unpublished source
> code, and so have no independent audit of what happens to packets within
> them.
>
> Linux and the public 'BSDs have published source code that can be
> audited.  Linux is known to apply its packet filtering algorithms as
> close to the drivers as possible.
>
> > Finally, if it were behind a hardware firewall, or router, how could
> > any unwanted packets get on the lan?
>
> They generally can't, without an invitation.  NAT relies upon outbound
> requests from a connection-oriented protocol (like TCP) to establish a
> return path.  If the firewall is NATted, only packets that have been
> "invited" to return can get in.
>
> If the firewall is not a NAT, there's more opportunities for directed
> packets to get into the LAN, but the firewall's packet filters will
> still be applied before Windows sees the packets.  It's holes don't
> apply in that case.
>
> Of course, most modern attacks are in the browser (or mail client),
> where a user, by loading a malicious page (or attachment), gives an
> attacker many invitations to deliver packets to the target machine.
> Here again, the auditable nature of open source software tends to expose
> flaws that an attacker would use to escape the browser's boundaries, and
> again to obtain elevated privileges.
>
> Windows is simply *not safe* to browse the internet with a direct
> connection, and only slightly safer behind a physical firewall.
>
> Phil
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
>



-- 
SimonTek
912-398-6704
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ale.org/pipermail/ale/attachments/20130122/7d201562/attachment.html>