Skip to content
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

Arbitrary code execution in JiraAPIWrapper #4833

Closed
2 of 14 tasks
0gur1 opened this issue May 17, 2023 · 5 comments · Fixed by #6992
Closed
2 of 14 tasks

Arbitrary code execution in JiraAPIWrapper #4833

0gur1 opened this issue May 17, 2023 · 5 comments · Fixed by #6992
Labels
13 security 🤖:security Related to security issues, CVEs

Comments

@0gur1
Copy link

0gur1 commented May 17, 2023

System Info

LangChain version:0.0.171
windows 10

Who can help?

No response

Information

  • The official example notebooks/scripts
  • My own modified scripts

Related Components

  • LLMs/Chat Models
  • Embedding Models
  • Prompts / Prompt Templates / Prompt Selectors
  • Output Parsers
  • Document Loaders
  • Vector Stores / Retrievers
  • Memory
  • Agents / Agent Executors
  • Tools / Toolkits
  • Chains
  • Callbacks/Tracing
  • Async

Reproduction

  1. Set the environment variables for jira and openai
import os
from langchain.utilities.jira import JiraAPIWrapper
os.environ["JIRA_API_TOKEN"] = "your jira api token"
os.environ["JIRA_USERNAME"] = "your username"
os.environ["JIRA_INSTANCE_URL"] = "your url"
os.environ["OPENAI_API_KEY"] = "your openai key"
  1. Run jira
jira = JiraAPIWrapper()
output = jira.run('other',"exec(\"import os;print(os.popen('id').read())\")")
  1. The id command will be executed.
    Commands can be change to others and attackers can execute arbitrary code.

Expected behavior

The code can be executed without any check.

@aditya-pethe
Copy link
Contributor

@zywilliamli @hwchase17

I think the options here are to either a) check code to a limited number of allowed actions, or b) remove the "other" method from the tool.

It looks like we want the jira tool to:

  1. Create an issue
  2. search jira
  3. get projects

I'm not sure what other functionality we want to extend to with self.other, maybe y'all know how to proceed best

@JamalRahman
Copy link
Contributor

This is another critical bug that is deployment breaking for many: https://nvd.nist.gov/vuln/detail/CVE-2023-34540

See: #4849 #6627

hwchase17 pushed a commit that referenced this issue Jul 5, 2023
…API wrapper (#6992)

This fixes #4833 and the critical vulnerability
https://nvd.nist.gov/vuln/detail/CVE-2023-34540

Previously, the JIRA API Wrapper had a mode that simply pipelined user
input into an `exec()` function.
[The intended use of the 'other' mode is to cover any of Atlassian's API
that don't have an existing
interface](https://github.com/hwchase17/langchain/blob/cc33bde74ff2e050a400e4451e04ff5b32c4a7bd/langchain/tools/jira/prompt.py#L24)

Fortunately all of the [Atlassian JIRA API methods are subfunctions of
their `Jira`
class](https://atlassian-python-api.readthedocs.io/jira.html), so this
implementation calls these subfunctions directly.

As well as passing a string representation of the function to call, the
implementation flexibly allows for optionally passing args and/or
keyword-args. These are given as part of the dictionary input. Example:
```
    {
        "function": "update_issue_field",   #function to execute
        "args": [                           #list of ordered args similar to other examples in this JiraAPIWrapper
            "key",
            {"summary": "New summary"}
        ],
        "kwargs": {}                        #dict of key value keyword-args pairs
    }
```

the above is equivalent to `self.jira.update_issue_field("key",
{"summary": "New summary"})`

Alternate query schema designs are welcome to make querying easier
without passing and evaluating arbitrary python code. I considered
parsing (without evaluating) input python code and extracting the
function, args, and kwargs from there and then pipelining them into the
callable function via `*f(args, **kwargs)` - but this seemed more
direct.

@vowelparrot @dev2049

---------

Co-authored-by: Jamal Rahman <jamal.rahman@builder.ai>
@aiakubovich
Copy link

@hwchase17

Hi. I still getting this error in scan: https://nvd.nist.gov/vuln/detail/CVE-2023-34540
Can we reopen?

@hwchase17
Copy link
Contributor

@aiakubovich for Jira, this should be fixed in most recent version, so updating langchain version should remove the error

aerrober pushed a commit to aerrober/langchain-fork that referenced this issue Jul 24, 2023
…API wrapper (langchain-ai#6992)

This fixes langchain-ai#4833 and the critical vulnerability
https://nvd.nist.gov/vuln/detail/CVE-2023-34540

Previously, the JIRA API Wrapper had a mode that simply pipelined user
input into an `exec()` function.
[The intended use of the 'other' mode is to cover any of Atlassian's API
that don't have an existing
interface](https://github.com/hwchase17/langchain/blob/cc33bde74ff2e050a400e4451e04ff5b32c4a7bd/langchain/tools/jira/prompt.py#L24)

Fortunately all of the [Atlassian JIRA API methods are subfunctions of
their `Jira`
class](https://atlassian-python-api.readthedocs.io/jira.html), so this
implementation calls these subfunctions directly.

As well as passing a string representation of the function to call, the
implementation flexibly allows for optionally passing args and/or
keyword-args. These are given as part of the dictionary input. Example:
```
    {
        "function": "update_issue_field",   #function to execute
        "args": [                           #list of ordered args similar to other examples in this JiraAPIWrapper
            "key",
            {"summary": "New summary"}
        ],
        "kwargs": {}                        #dict of key value keyword-args pairs
    }
```

the above is equivalent to `self.jira.update_issue_field("key",
{"summary": "New summary"})`

Alternate query schema designs are welcome to make querying easier
without passing and evaluating arbitrary python code. I considered
parsing (without evaluating) input python code and extracting the
function, args, and kwargs from there and then pipelining them into the
callable function via `*f(args, **kwargs)` - but this seemed more
direct.

@vowelparrot @dev2049

---------

Co-authored-by: Jamal Rahman <jamal.rahman@builder.ai>
obi1kenobi added a commit to obi1kenobi/advisory-database that referenced this issue Aug 28, 2023
That advisory corresponds to:
- this issue, which is closed as completed: langchain-ai/langchain#4833
- this PR, which is merged: langchain-ai/langchain#6992
- this fix release, which references the above PR in the release notes: https://github.com/langchain-ai/langchain/releases/tag/v0.0.225
@obi1kenobi
Copy link
Collaborator

obi1kenobi commented Aug 28, 2023

Confirming this is fixed in #6992 and published in v0.0.225. Versions v0.0.225 and newer should not be affected.

You can confirm this by noting:

@aiakubovich I'm opening a PR to the advisory database to update that CVE as fixed in v0.0.225, which should stop it from being reported on your end once your scanner tool sees the updated database entry.

If you're still seeing this problem ~next week, please give us a ping and we can dig in deeper together.

Thanks for your patience on this! We're working to make this process smoother in the future.

CVE-2023-34540

sethmlarson pushed a commit to pypa/advisory-database that referenced this issue Aug 28, 2023
That advisory corresponds to:
- this issue, which is closed as completed: langchain-ai/langchain#4833
- this PR, which is merged: langchain-ai/langchain#6992
- this fix release, which references the above PR in the release notes: https://github.com/langchain-ai/langchain/releases/tag/v0.0.225
@eyurtsev eyurtsev added 13 security 🤖:security Related to security issues, CVEs labels Mar 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
13 security 🤖:security Related to security issues, CVEs
Projects
None yet
7 participants