libxml2 and CVE-2024-25062
Good day All, Apologies for the silly question but I am new to F5, when I was running iHealth on my BigIP running V17.1.2.1 it flagged the above CVE-2024-25062. Is this for the version 17.1.0 - 17.1.2 which includes mine, in general? I am thinking this doesn't affect me because when I look in services (local traffic -> profiles -> services) I don't even see XML, unless I am looking in the wrong place. I also went into the command line did a find on libxml2 and xml2 and didn't find and directories. When I did a find on just xml I did find a few directories but nothing on xml2. So is it safe to say this doesn't affect me or am I wrong? Thank you in advance!! Warren
Issues modifying XML content with stream profile & iRule
I've taken an iRule from another DevCentral post and modified it to fit my application. when HTTP_REQUEST { Disable the stream filter for all requests STREAM::disable LTM does not uncompress response content, so if the server has compression enabled and it cannot be disabled on the server, we can prevent the server from sending a compressed response by removing the compression offerings from the client HTTP::header remove "Accept-Encoding" } when HTTP_RESPONSE { Check if response type is text if {[HTTP::header value Content-Type] contains "text/xml"}{ Replace http:// with https:// STREAM::expression {@http:\\/\\/applicationdomain@https:\\/\\/applicationdomain@} Enable the stream filter for this response only STREAM::enable } } The stream profile is successfully replacing the HTTP: with HTTPS:, but is also including the additional backslash and a Silverlight (smh) error pops up When I remove the second backslash in the iRule, the HTTP: is no longer replaced with HTTPS:, and I'm back to square one. Any ideas on what I might be doing wrong? Thanks in advance!
XML Threat Prevention
Where should security live? The divide between operations and application developers is pretty wide, especially when it comes to defining who should be ultimately responsible for application security. Mike Fratto and I have often had lively discussions (read: arguments) about whether security is the responsibility of the developer or the network and security administrators. It's wholly inappropriate to recreate any of these discussions here, as they often devolve to including the words your mother said not to use in public. 'Nuff said. The truth is that when XML enters the picture then the responsibility for securing that traffic has to be borne by both the network/security administrators and the developers. While there is certainly good reason to expect that developers are doing simply security checks for buffer overflows, length restrictions on incoming data, and strong typing, the fact is that there are some attacks in XML that make it completely impractical to check for in the code. Let's take a couple of attack types as examples. XML Entity Expansion This attack is a million laughs, or at least a million or more bytes of memory. Applications need to parse XML in order to manipulate it, so the first thing that happens when XML hits an application is that it is parsed - before the developer even has a chance to check it. In an application server this is generally done before the arguments to the specific operation being invoked are marshaled - meaning it is the application server, not the developer that is responsible for handling this type of attack. These messages can be used to force recursive entity expansion or other repeated processing that exhausts server resources. The most common example of this type of attack is the "billion laughs" attack, which is widely available. The CPU is monopolized while the entities are being expanded, and each entity takes up X amount of memory - eventually consuming all available resources and effectively preventing legitimate traffic from being processed. It's essentially a DoS (Denial of Service) attack. ... ]> &ha128; It is accepted that almost all traditional DoS attacks (ping of death, teardrop, etc...) should be handled by a perimeter security device - a firewall or an application delivery controller - so why should a DoS attack that is perpetrated through XML be any different? It shouldn't. This isn't a developer problem, it's a parser problem and for the most part developers have little or no control over the behavior of the parser used by the application server. The application admin, however, can configure most modern parsers to prevent this type of attack, but that's assuming that their parser is modern and can be configured to handle it. Of course then you have to wonder what happens if that arbitrary limit inhibits processing of valid traffic? Yeah, it's a serious problem. SQL Injection SQL Injection is one of the most commonly perpetrated attacks via web-based applications. It consists basically of inserting SQL code into string-based fields which the attacks thinks (or knows) will be passed to a database as part of an SQL query. This type of attack can easily be accomplished via XML as well simply by inserting the appropriate SQL code into a string element. Aha! The developer can stop this one, you're thinking. After all, the developer has the string and builds the SQL that will be executed, so he can just check for it before he builds the string and sends it off for execution. While this is certainly true, there are myriad combinations of SQL commands that might induce the database to return more data than it should, or to return sensitive data not authorized to the user. This extensive list of commands and combinations of commands would need to be searched for in each and every parameter used to create an SQL query and on every call to the database. That's a lot of extra code and a lot of extra processing - which is going to slow down the application and impede performance. And when a new attack is discovered, each and every function and application needs to be updated, tested, and re-deployed. I'm fairly certain developers have better ways to spend their time than updating parameter checking in every function in every application they have in production. And we won't even talk about third-party applications and the dangers inherent in that scenario. One of the goals of SOA is engendering reuse, and this is one of the best examples of taking advantage of reuse in order to ensure consistent behavior between applications and to reduce the lengthy development cycle required to update, test, and redeploy whenever a new attack is discovered. By placing the onus for keeping this kind of attack from reaching the server on an edge device such as an application firewall like F5's application firewall, updates to address new attacks are immediately applied to all applications and there is no need to recode and redeploy applications. Although there are some aspects of security that are certainly best left to the developer, there are other aspects of security that are better deployed in the network. It's the most effective plan in terms of effort, cost, and consistent behavior where applications are concerned. Imbibing: Mountain Dew Technorati tags: security, application security, application firewall, XML, developers, networking, application delivery
Deploy BIG-IP Edge Client (iOS) with configuration string
Greetings all, I'm very new to F5 (only responsible for deploying Edge Client with MDM) and need some basic assistance. Are there any more examples available for Configuration XML strings used to deploy the Edge Client via MDM and VPP to iOS devices with connection settings already established? Specifically we are utilizing JAMF as our MDM. Apps can be given configuration settings in their deployment. I was attempting to use the below string but I'm getting an error - 'Incorrect Format'. Help is appreciated. Thanks! We are using user name and password for authentication, and it is an SSL appliance. IPv4 UserDefinedName The Name of our connection VPN AuthName $USERNAME RemoteAddress our F5 Address OnDemandMatchAppEnabled VPNSubType [com.f5.F5-Edge-Client.vpnplugin](//com.f5.F5-Edge-Client.vpnplugin) VPNType VPNXML and WSDLs
Hello All, Is there a way for the BigIP to exposed the WSDLs when a client request them instead of the backend server. I have set a Security Policy, a XML profile and installed the WSDLs needed. I had a former infrastructure with IBM Datapower from where this was possible, I wonder if this is possible with the ASM module Customer request is like this GET /foobar-webservices/test?wsdl HTTP/1.1 Host: foo.bar:443 Connection: close Thank you.
Can I allow Buffer Overflow attack signatures in just an XML request?
The website has an upload page where people can submit receipts. The request looks like this: 4AAQSkD6RXhpZgAuocAAcAAAgMAAAAPgAAAAAc6gAAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA..... We have determined that the "A"s represent the white space in the image and since it is a receipt, a large area of it is white, but this is throwing the Generic buffer overflow attempt 1 attack signature due to the large sequence of "A"s. The question is if there is a way to just turn off this signature for this URI. Since the overflow false positive is in the XML I do not know of a way to do this, and we do not what to have to turn off buffer overflow signatures for the whole site. We only have one policy for the whole site and are unable to use the LTM side to split up the traffic to different policies. Thank you.
ASM JSON/XML payload detection & Automatically detect advanced protocols
Hello team, I have a question regarding the learning suggestions, I want to know if it is possible for the ASM to suggest the association of an XML profile to a specific URL. In other words, is there a way to configure the ASM so that when XML traffic passes through it then a learning suggestion rises saying "you have to associate an XML for this URL" In this article : https://support.f5.com/kb/en-us/products/big-ip_asm/manuals/product/asm-getting-started-12-1-0/3.html The Policy Builder builds the security policy as follows: Examines application content and creates XML or JSON profiles as needed (if the policy includes JSON/XML payload detection) ...etc we can read explicitly that it is possible IF we enable the "JSON/XML payload detection" then the answer to my question is "Yes" . The problem is that I can't find this "JSON/XML payload detection" option in the GUI. Could you please help on this ? Many thanks, KarimPerl Ltm Config To Xml/Excel (version 3.1)
Problem this snippet solves: This code is an improvement of "Perl Ltm Config To Xml (version 2)" published on previous DevCentral (https://devcentral.f5.com/s/articles/perl-ltm-config-to-xml-version-2-1009) queries the components of a virtual servers configuration and prints it out in an XML format. Is recursive through partitions and prints the following data: VS_name VS_IP: IP and port RD (route domain) VS_state: status (ex. green) and state (ex. enabled) Profiles: name, type, context. If SSL profile aditional info: certificate, chain, key, cipher list Persistence iRules: order and name Pool_name LB-method: method, minimum active members Member: name, IP, port, ratio, priority, status and state Monitors: name, interval, timeout. If HTTP/HTTPS monitors additional info: Send and Receive strings SNAT_name SNAT_members Has a new option "-s" or "-simplified" which outputs multiple values like the profile list or pool members into a unique XML field. Purpose of simplified mode is to be able to have one Virtual Server per row on Excel, with lists showing on a single cell. This code has been tested on BIG-IP version 12.1 and 14.1. How to use this snippet: Default mode: ./LTM-to-XML.pl bigip uid pwd > result.xml Example for simplified mode and removal of partition information: ./LTM-to-XML.pl -s 127.0.0.1 uid pwd | sed "s/\/.*app\///g" | sed "s/\/Common\///g" > result.xml The XML can be dragged and dropped on MS Excel and opened as an XML table. Code : (see ZIP file) Tested this on version: 12.1, 14.1
