Stories
Slash Boxes
Comments

SoylentNews is people

posted by Fnord666 on Friday March 20 2020, @08:41AM   Printer-friendly
from the little-bobby-tables dept.

Arthur T Knackerbracket has found the following story:

Cisco Systems has fixed three high-severity vulnerabilities in its software-defined networking for wide-area network (SD-WAN) solutions for business users. If exploited, the flaws could enable bad actors to execute commands with root privileges on affected systems. To exploit the vulnerabilities attackers need to first be local and authenticated.

The three flaws are located in various Cisco hardware and software products running the company’s SD-WAN software earlier than Release 19.2.2 (the fixed release). Hardware includes the company’s SD-WAN solutions: vBond and vSmart controllers (which implements network connectivity), the vManage Network Management system (the centralized management platform) and the vBond Orchestrator software (which performs authentication of all elements in the network). Also affected are various vEdge routers, and the corresponding vEdge cloud router platform.

“The Cisco Product Security Incident Response Team is not aware of any public announcements or malicious use of the vulnerability that is described in this advisory,” according to Cisco’s Wednesday advisory.

Oblig xkcd: Exploits of a mom


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by Hyperturtle on Friday March 20 2020, @01:02PM (2 children)

    by Hyperturtle (2824) on Friday March 20 2020, @01:02PM (#973459)

    Based on my experiences--across vendors and platforms and what people think it really means... SD-WAN is actually all stuff that already had been done via configuration anyway, and often on disparate components that allow for a more modular or non-vendor-specific approach. It still required one or a few people to understand how at least some of it works (while perhaps relying on the wizards for whatever that they don't)

    Vendors and even service providers are keen on selling "all-in-one" devices that pretty much host virtual machines to do the functions that discrete components used to do.

    Now if the 'bare-metal' fails, poof goes your VPN and filter and whatever-else-they-promised. Or if the host of all that is compromised, it is not too far-fetched to believe the underlying guest virtual machines are soon to be compromised as well.

    Anyway 'v' anything usually means more patching per hardware instance; gone are the days when some unassuming router could go with a few years of uptime without having been found to contain some vulnerability, flaw, or bug.

    I am speaking generally; many vendors both share the same problems (and open-source libraries, it seems) as well as having unique problems that make an agnostic topology more difficult to maintain.

    Anyway uh. I do not have a positive experience with all-in-one solutions installed as a cure-all for QoS and internet filtering and other things; often the service provider (if you subscribe or lease the SD-WAN hardware's management--even if you bought the hardware yourself) are frequently unable to tell you how it actually works.

    If you have a service provider that can't tell you what the quality of service for voip or video is doing beyond showing a screenshot of a checkbox that shows "QoS" is enabled, you might find that when it comes time to patch, they will not know how to fix anything broken... because they don't know how it works and won't be able to identify problems when it breaks.

    If all your service provider does is open a direct ticket to the hardware or software provider after rebooting the stuff a few times, then you might want to consider learning more about it yourself (or tasking someone within your organization to at least download the manual and look at it and compare the examples with what is configured... if they are identical then you can probably do it yourself! I've seen places that were being coaxed to change their network addressing because it wasn't "compatible" with the SD-WAN hardware--and by that the network had existing 192.168.1.x addressing that was in conflict... the SD-WAN hardware itself each had addressable nics and so on in the config, but the people setting it up had a 3-ring binder and were not deviating from the screen shots it contained...)

    uh

    Maybe that all sounds like I am against SD-WAN. I am not, but I am against how it's sold, marketed and supported. Anyone good with IT support probably could figure it out, but as the scale grows (maybe if you have many branch offices connecting over the internet via new vpns created by these things) you might need outside support. But if you only have a few spokes connecting to a main office hub (or in other words, a few small offices connecting to a bigger one to allow cross-connectivity for chat and email and file shares on a few local servers) you just might be able to pull this all off in your own IT team.

    Anyway. These products... the OS releases are often "Agile" influenced, so be prepared to patch at unexpected intervals as outside groups find issues no one tested for before the software is released.

    It may be you are the beta tester, and they call it insider or rapid-release or enhancement cycles. If you just want to keep it working, look for their extended release or stable versions... Cisco has long term and short term OSes for hardware you probably will keep for the long term, so make sure you prioritize the version you run based on how often you want to futz with the hardware after it's supposed to be working and the config pretty much finalized.

    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 3, Insightful) by sjames on Friday March 20 2020, @05:09PM (1 child)

    by sjames (2882) on Friday March 20 2020, @05:09PM (#973557) Journal

    Personally, I *AM* against the various soft networks. Not the concept itself, but for the layer of indirection that keeps you from actually understanding what is happening on the network. It doesn't do anything that you couldn't already do with the pre-existing technology, it just adds buzzword compliance.

    • (Score: 2) by Hyperturtle on Wednesday March 25 2020, @04:25PM

      by Hyperturtle (2824) on Wednesday March 25 2020, @04:25PM (#975522)

      yeah I think this all just makes it harder.

      I know all about this compliance you speak of, and buzzwords sure can make that worse... it just hides the complexity while making it harder for the non-technical to uniformly apply some compliance script to things they might not understand.

      It's already hard enough to meet a (possibly arbitrary) compliance standard without having an easy means to justify the workings some black box that no one knows what happens in it when the wizard is alseep, and their support don't exactly know how it works either.

      SDNs can make a lot of things... easier. More functionality can be made available for cheaper. But watch out if it breaks or there are legal questions (or customer demands about security or privacy) when even the people that support are clueless.

      It's always a good idea to find out if someone knows what is going on under the hood--if not very well, then at least in theory...