back to article If you haven't potentially exposed 1000s of customers once again with networking vulns, step forward... Not so fast, Palo Alto Networks

Palo Alto Networks has emitted its second software update in as many weeks to address a potentially serious security vulnerability in its products. The vendor on Wednesday issued an advisory for CVE-2020-2034, a remote code execution flaw in its PAN-OS GlobalProtect portal, which can be exploited by a remote unauthenticated …

  1. Sandtitz Silver badge

    Not enabled by default

    "Palo Alto confirmed to The Register that GlobalProtect is not enabled by default, though anecdotal evidence suggests it's widely used."

    Worthless comment.

    My experience with firewalls and security products is that no features are enabled by default. Maybe basic NAT routing at most or management access.

    If there was a 0-day with e.g. VPN, would the vendor just brush it away saying that feature is not on by default? (not saying Palo Alto is guilty of this)

  2. Version 1.0 Silver badge

    Bugs love "features"

    In general the people writing firewall code understand all the risks and "drop-all" is the default rule. But when teams are created to add "features" you're dealing with completely different attitudes so bugs will creep into the code.

    1. Anonymous Coward
      Anonymous Coward

      Re: Bugs love "features"

      "drop all" looks to be and indeed is a default rule in most cases, when you understand what and how a firewall works you'll see that actually a firewall needs a rule to allow traffic as without a rule it has no clue what to do with incoming (from in or outside) traffic and send to null is the most obvious thing to do when you don't know what to do, maybe log and alert too but those are secondary actions.

      incoming traffic --> what to do --> don't have an instruction --> drop #--> have an instruction --> follow that.

      the most basic *firewall is a nat device, incoming traffic to the address that has nat on it must match an existing session (if its not a well known port already configured to forward inbound to something) no session match (source IP & Source Port & destination IP & Destination port) no match & it can't forward traffic as it doesn't have any detail of what to forward to.

      Someone has to write "functionality" to overcome the intrinsic security of a basic DB/table/array not having detail of what to do with something it doesn't know about.

      * Basic firewall as the nat table is/can be a subset of a firewall session table.

      1. Version 1.0 Silver badge

        Re: Bugs love "features"

        LOL, of course - you write your rules to allow access to the ports and addresses you trust and you drop everything else ... but then a "feature" allows its packets through without documented exactly what is happening.

    2. Anonymous Coward
      Anonymous Coward

      Re: Bugs love "features"

      You do understand what global protect is right?

      It's not the firewall bit with the hole, it's yet another problem with a ssl vpn. All vendor's Ssl vpn's have continuous problems, mainly because of the house of cards this stuff is built using, combined with what is to be gained by breaking it. Its a big old prize.

  3. James12345

    The important part of this story is lost due to the headline

    Dear El Reg, you have this one upside down. The important story here is that F5 have revised their advice. The Palo section is basically a non story, because the devices should already have been patched from an earlier issue. The fact that F5 now are saying that the workaround we said was OK isn't, so you've probably been pwned, is the real issue here, and because a snappy headline could only be worked out for the minor story, you've ended burying the big one.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2021