A highly privileged remote attacker, can gain unauthorized access to display contents of restricted directories by exploiting insufficient validation of path information in SAP Focused Run (Simple Diagnostics Agent 1.0) - version 1.0.

CVE-2022-27657

In Paramiko before 2.10.1, a race condition (between creation and chmod) in the write_private_key_file function could allow unauthorized information disclosure.

CVE-2022-24302: Changelog — Paramiko documentation

Evmos is the Ethereum Virtual Machine (EVM) Hub on the Cosmos Network. In versions of evmos prior to 2.0.1 attackers are able to drain unclaimed funds from user addresses. To do this an attacker must create a new chain which does not enforce signature verification and connects it to the target evmos instance. The attacker can use this joined chain to transfer unclaimed funds. Users are advised to upgrade. There are no known workarounds for this issue.

**Impact**

_What kind of vulnerability is it? Who is impacted?_

**Classification**

The vulnerability has been classified as critical with a score of 9.0 (highest). It has the potential to affect and drain unclaimed airdrop funds from Cosmos and Osmosis eligible user addresses.

**Disclosure**

The attack requires advanced knowledge of the internals of the core and application packages of IBC, IBC relayers, the Cosmos SDK AnteHandler, and the Evmos x/claims module. The step-by-step attack is described below:

1.  An actor creates a malicious chain with a custom AnteHandler that skips signature verification for transactions, specifically IBC MsgTransfer. This allows the attacker to impersonate any account by setting a custom sender address field of the IBC transfer message.
2.  The malicious actor then connects this newly created chain via IBC to Evmos and fills the recipient address from the transfer message with an address they control.
3.  Once the IBC packet containing the Transfer data is relayed to Evmos, it is processed by the claims module IBC middleware. Which migrates the claim records to the recipient address, which is owned by the attacker.
4.  The attacker then performs two airdrop Actions, claiming up to 75% of the total initial claimable amount.
5.  The Actor repeats steps 1., 2., and 3. for every address that has unclaimed funds from the airdrop. This automatically claims 75% of the unclaimable amount.
6.  The malicious actor performs the final Action, claiming 100% of all the user funds.
7.  Then, the attacker transfers the funds to another chain with a DEX (Osmosis, Cosmos Hub) via IBC.
8.  Finally, the attacker withdraws the total amount in fiat through a centralized exchange.

**Users impacted**

No users have suffered the loss of funds as no malicious chains have been connected to Evmos.

**Patches**

_Has the problem been patched? What versions should users upgrade to?_

The patch involves defining a list of authorized channels for chains that are connected to Evmos via IBC. This restricts the chains that have the capability of migrating users' claims records as per the specification. By default, the authorized destination channels are "channel-0" (Osmosis) and "channel-3" (Cosmos Hub).

Please upgrade your mainnet node and validator to v2.0.1 **ASAP**.

**Workarounds**

_Is there a way for users to fix or remediate the vulnerability without upgrading?_

No, the fix for the critical vulnerability is state machine breaking. An upgrade procedure must be coordinated with the nodes running the network.

**References**

_Are there any links users can visit to find out more?_

*   Claims module spec: evmos.dev/modules/claims
*   Cosmos SDK documentation: docs.cosmos.network
*   IBC documentation: ibc.cosmos.network

**For more information**

If you have any questions or comments about this advisory:

*   Reach out to the Core Team in Discord
*   Open an issue in tharsis/evmos
*   Email us at security@thars.is

Thanks to the Core IBC team at Interchain GmbH for the secure disclosure of this vulnerability

CVE-2022-24738: Malicious Migration of Claimable Amount through IBC

Buffer overflow vulnerabilities exist in FRRouting through 8.1.0 due to the use of strdup with a non-zero-terminated binary string in isis_nb_notifications.c.

At Line 470 in the code below, we call yang_data_new, which will further call strdup(raw_pdu). However, raw_pdu is not guaranteed to be a zero-terminated string and, thus, will lead to a stack overflow in strdup. When I set raw_pdu[raw_pdu_len - 1] to \0, then the bug disappears. Note that strdup should be used with a C-string.

In the same file, isis_nb_notifications.c, there are **8 places** where yang_data_new are used with raw_pdu and, thus, may have the overflow bug. Please check and suggest a fix. I can give a pull request then.

void isis\_notif\_id\_len\_mismatch(const struct isis\_circuit \*circuit,

uint8\_t rcv\_id\_len, const char \*raw\_pdu,

size\_t raw\_pdu\_len)

{

const char \*xpath = "/frr-isisd:id-len-mismatch";

struct list \*arguments = yang\_data\_list\_new();

char xpath\_arg\[XPATH\_MAXLEN\];

struct yang\_data \*data;

struct isis\_area \*area = circuit->area;

notif\_prep\_instance\_hdr(xpath, area, "default", arguments);

notif\_prepr\_iface\_hdr(xpath, circuit, arguments);

snprintf(xpath\_arg, sizeof(xpath\_arg), "%s/pdu-field-len", xpath);

data = yang\_data\_new\_uint8(xpath\_arg, rcv\_id\_len);

listnode\_add(arguments, data);

snprintf(xpath\_arg, sizeof(xpath\_arg), "%s/raw-pdu", xpath);

data = yang\_data\_new(xpath\_arg, raw\_pdu);

listnode\_add(arguments, data);

What follows is the output of the address sanitizer:

    ==48351==ERROR: AddressSanitizer: dynamic-stack-buffer-overflow on address 0x7ffe596a3a76 at pc 0x000000543e97 bp 0x7ffe596a3020 sp 0x7ffe596a27e0
    READ of size 23 at 0x7ffe596a3a76 thread T0
        #0 0x543e96 in strdup (/home/parallels/myfrr/isisd/isisd+0x543e96)
        #1 0x84f73d in yang_data_new /home/parallels/myfrr/lib/yang.c:608:17
        #2 0x6716eb in isis_notif_id_len_mismatch /home/parallels/myfrr/isisd/isis_nb_notifications.c:470:9
        #3 0x5cedcf in isis_handle_pdu /home/parallels/myfrr/isisd/isis_pdu.c:1706:3

CVE-2022-26126: isisd: misusing strdup leads to stack overflow · Issue #10505 · FRRouting/frr

In Expat (aka libexpat) before 2.4.5, an attacker can trigger stack exhaustion in build_model via a large nesting depth in the DTD element.

It is possible to trigger stack exhaustion in build\_model function if  
depth of nested children in DTD element is large enough. This happens  
because build\_node is a recursively called function within build\_model.

The code has been adjusted to run iteratively. It uses the already  
allocated heap space as temporary stack (growing from top to bottom).

Output is identical to recursive version. No new fields in data  
structures were added, i.e. it keeps full API and ABI compatibility.  
Instead the numchildren variable is used to temporarily keep the  
index of items (uint vs int).

Documentation and readability improvements kindly added by Sebastian.

    cat > poc.c << EOF
     #include <err.h>
     #include <expat.h>
     #include <stdio.h>
    
     XML_Parser parser;
    
     static void XMLCALL
     dummy_element_decl_handler(void *userData, const XML_Char *name,
                                XML_Content *model) {
       XML_FreeContentModel(parser, model);
     }
    
     int main(int argc, char *argv[]) {
       FILE *fp;
       char *p = NULL;
       size_t s = 0;
       ssize_t l;
       if (argc != 2)
         errx(1, "usage: poc poc.xml");
       if ((parser = XML_ParserCreate(NULL)) == NULL)
         errx(1, "XML_ParserCreate");
       XML_SetElementDeclHandler(parser, dummy_element_decl_handler);
       if ((fp = fopen(argv[1], "r")) == NULL)
         err(1, "fopen");
       while ((l = getline(&p, &s, fp)) > 0)
         if (XML_Parse(parser, p, (int)l, XML_FALSE) != XML_STATUS_OK)
           errx(1, "XML_Parse");
       XML_ParserFree(parser);
       free(p);
       fclose(fp);
       return 0;
     }
    EOF
    cc -std=c11 -D_POSIX_C_SOURCE=200809L -lexpat -o poc poc.c
    

    cat > poc.xml.zst.b64 << EOF
    KLUv/aQkACAAPAEA+DwhRE9DVFlQRSB1d3UgWwo8IUVMRU1FTlQgdXd1CigBAHv/58AJAgAQKAIA
    ECgCABAoAgAQKAIAECgCABAoAgAQKHwAAChvd28KKQIA2/8gV24XBAIAECkCABApAgAQKQIAECkC
    ABApAgAQKQIAEClVAAAgPl0+CgEA4A4I2VwwnQ==
    EOF
    base64 -d poc.xml.zst.b64 | zstd -d > poc.xml

CVE-2022-25313: [CVE-2022-25313] lib: Prevent stack exhaustion in build_model by ferivoz · Pull Request #558 · libexpat/libexpat

xmlparse.c in Expat (aka libexpat) before 2.4.5 allows attackers to insert namespace-separator characters into namespace URIs.

sebageek added a commit to sapcc/asr1k-neutron-l3 that referenced this issue

Feb 28, 2022

Newer version of libexpat have a mitigation for CVE-2022-25236 in place,
which disallows the use of certain characters as namespace separators
(to my understanding this is the separator used to separate namespace
and tag name in the parsed xml output we receive from the library). We
implicitly use libexpat via xmltodict.parse(), xmltodict uses a default
of ':', which now is invalid. Using ':' as separator results in the
following exception:

xml.parsers.expat.ExpatError: out of memory: line 1, column 0

This can also be reproduced with this python snippet:

xmltodict.parse("<foo></foo>", process\_namespaces=True)

To mitigate this we need to use a different separator. xmltodict.parse()
exposes this as an argument, so passing namespace\_separator=' ' (as
recommended by libexpat as a char that is not part of an url, see bug
reports below or CVE) solves the problem for us. From what I can see
this also doesn't require any other changes on our side.

Relevant change in libexpat:
 \* libexpat/libexpat#561

Relevant bugreports:
 \* libexpat/libexpat#572
 \* martinblech/xmltodict#289

CVE-2022-25236: [CVE-2022-25236] lib: Protect against insertion of namesep characters into namespace URIs by hartwork · Pull Request #561 · libexpat/libexpat

SAP NetWeaver Application Server ABAP, SAP NetWeaver Application Server Java, ABAP Platform, SAP Content Server 7.53 and SAP Web Dispatcher are vulnerable for request smuggling and request concatenation. An unauthenticated attacker can prepend a victim's request with arbitrary data. This way, the attacker can execute functions impersonating the victim or poison intermediary Web caches. A successful attack could result in complete compromise of Confidentiality, Integrity and Availability of the system.

CVE-2022-22536

SAP ERP HCM Portugal - versions 600, 604, 608, does not perform necessary authorization checks for a report that reads the payroll data of employees in a certain area. Since the affected report only reads the payroll information, the attacker can neither modify any information nor cause availability impacts.

CVE-2022-22535

Due to insufficient encoding of user input, SAP NetWeaver allows an unauthenticated attacker to inject code that may expose sensitive data like user ID and password. These endpoints are normally exposed over the network and successful exploitation can partially impact confidentiality of the application.

CVE-2022-22534

Due to improper error handling in SAP NetWeaver Application Server Java - versions KRNL64NUC 7.22, 7.22EXT, 7.49, KRNL64UC, 7.22, 7.22EXT, 7.49, 7.53, KERNEL 7.22, 7.49, 7.53, an attacker could submit multiple HTTP server requests resulting in errors, such that it consumes the memory buffer. This could result in system shutdown rendering the system unavailable.

Tag

#sap