Skip to content

Conversation

@smola
Copy link
Member

@smola smola commented Apr 25, 2025

Current stacktrace filtering code returned no location if all frames are outside the current working directory or in site-packages. This often happens in the following scenarios:

  • asyncio code: the full stacktrace may be in site-packages, outside app directory.
  • running applications installed in site-packages.

In these cases, vulnerabilities were being dropped. The fix includes:

  • First, the first frame that is not a frozen package (or <template> or anything starting with <), and not in the stdlib path (but potentially in the purelib path) is found and saved as a backup frame, if any. If none is found, no location is returned.
  • From there, the first frame that is not a frozen package, not in the stdlib path, and not in the purelib path is checked. If found, that location is returned. Otherwise, the backup frame is returned.
  • Code to relativize path to the vulnerability location is now extended to account for the fact that we can return paths within the purelib path.

In practice, this means that vulnerabilities found in site-packages, with no other relevant frame, will be reported.

APPSEC-57414

Checklist

  • PR author has checked that all the criteria below are met
  • The PR description includes an overview of the change
  • The PR description articulates the motivation for the change
  • The change includes tests OR the PR description describes a testing strategy
  • The PR description notes risks associated with the change, if any
  • Newly-added code is easy to change
  • The change follows the library release note guidelines
  • The change includes or references documentation updates if necessary
  • Backport labels are set (if applicable)

Reviewer Checklist

  • Reviewer has checked that all the criteria below are met
  • Title is accurate
  • All changes are related to the pull request's stated goal
  • Avoids breaking API changes
  • Testing strategy adequately addresses listed risks
  • Newly-added code is easy to change
  • Release note makes sense to a user of the library
  • If necessary, author has acknowledged and discussed the performance implications of this PR as reported in the benchmarks PR comment
  • Backport labels are set in a manner that is consistent with the release branch maintenance policy

@smola smola added the ASM Application Security Monitoring label Apr 25, 2025
@github-actions
Copy link
Contributor

github-actions bot commented Apr 25, 2025

CODEOWNERS have been resolved as:

releasenotes/notes/fix-iast-stacktrace-filter-6afd6a9568f36d99.yaml     @DataDog/apm-python
ddtrace/appsec/_iast/_stacktrace.c                                      @DataDog/asm-python
ddtrace/appsec/_iast/_stacktrace.pyi                                    @DataDog/asm-python
ddtrace/appsec/_iast/taint_sinks/_base.py                               @DataDog/asm-python
tests/appsec/iast/taint_sinks/test_weak_hash.py                         @DataDog/asm-python
tests/appsec/iast_memcheck/fixtures/stacktrace.py                       @DataDog/asm-python
tests/appsec/iast_memcheck/test_iast_mem_check.py                       @DataDog/asm-python

@github-actions
Copy link
Contributor

github-actions bot commented Apr 25, 2025

Bootstrap import analysis

Comparison of import times between this PR and base.

Summary

The average import time from this PR is: 232 ± 2 ms.

The average import time from base is: 234 ± 2 ms.

The import time difference between this PR and base is: -1.73 ± 0.1 ms.

Import time breakdown

The following import paths have shrunk:

ddtrace.auto 1.954 ms (0.84%)
ddtrace.bootstrap.sitecustomize 1.286 ms (0.55%)
ddtrace.bootstrap.preload 1.286 ms (0.55%)
ddtrace.internal.products 1.286 ms (0.55%)
ddtrace.internal.remoteconfig.client 0.641 ms (0.28%)
ddtrace 0.669 ms (0.29%)

@pr-commenter
Copy link

pr-commenter bot commented Apr 25, 2025

Benchmarks

Benchmark execution time: 2025-05-06 11:08:05

Comparing candidate commit f2c630e in PR branch smola/refine-stacktrace with baseline commit e55ca19 in branch main.

Found 0 performance improvements and 1 performance regressions! Performance is the same for 388 metrics, 5 unstable metrics.

scenario:iast_aspects-ospathnormcase_aspect

  • 🟥 execution_time [+404.618ns; +481.316ns] or [+11.838%; +14.082%]

@smola smola force-pushed the smola/refine-stacktrace branch from 0a215f0 to afe4076 Compare April 28, 2025 06:08
@smola smola marked this pull request as ready for review April 29, 2025 15:37
@smola smola requested review from a team as code owners April 29, 2025 15:37
@smola smola requested review from mabdinur and wantsui April 29, 2025 15:37
@smola smola force-pushed the smola/refine-stacktrace branch from 6df3fdf to 9e40427 Compare April 30, 2025 14:12
@smola smola force-pushed the smola/refine-stacktrace branch from 6dd320a to af5a923 Compare May 5, 2025 12:14
@smola smola force-pushed the smola/refine-stacktrace branch from ed7e891 to d37dbc4 Compare May 6, 2025 08:08
@smola
Copy link
Member Author

smola commented May 6, 2025

Pushed a fix to avoid serializing empty location fields in IAST, in a commit here to validate it, and in a separate PR: #13333

@smola smola force-pushed the smola/refine-stacktrace branch from d37dbc4 to f2c630e Compare May 6, 2025 10:22
@avara1986 avara1986 merged commit 20a96bb into main May 6, 2025
407 checks passed
@avara1986 avara1986 deleted the smola/refine-stacktrace branch May 6, 2025 11:46
@github-actions
Copy link
Contributor

github-actions bot commented May 6, 2025

The backport to 2.21 failed:

The process '/usr/bin/git' failed with exit code 1

To backport manually, run these commands in your terminal:

# Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add .worktrees/backport-2.21 2.21
# Navigate to the new working tree
cd .worktrees/backport-2.21
# Create a new branch
git switch --create backport-13272-to-2.21
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 20a96bb791aa98657ba85e77032f670a0ea1b028
# Push it to GitHub
git push --set-upstream origin backport-13272-to-2.21
# Go back to the original working tree
cd ../..
# Delete the working tree
git worktree remove .worktrees/backport-2.21

Then, create a pull request where the base branch is 2.21 and the compare/head branch is backport-13272-to-2.21.

smola added a commit that referenced this pull request May 7, 2025
Current stacktrace filtering code returned no location if all frames are
outside the current working directory or in site-packages. This often
happens in the following scenarios:
- asyncio code: the full stacktrace may be in site-packages, outside app
directory.
- running applications installed in site-packages.

In these cases, vulnerabilities were being dropped. The fix includes:
- First, the first frame that is not a frozen package (or `<template>`
or anything starting with `<`), and not in the stdlib path (but
potentially in the purelib path) is found and saved as a backup frame,
if any. If none is found, no location is returned.
- From there, the first frame that is not a frozen package, not in the
stdlib path, and not in the purelib path is checked. If found, that
location is returned. Otherwise, the backup frame is returned.
- Code to relativize path to the vulnerability location is now extended
to account for the fact that we can return paths within the purelib
path.

In practice, this means that vulnerabilities found in site-packages,
with no other relevant frame, will be reported.

[APPSEC-57414](https://datadoghq.atlassian.net/browse/APPSEC-57414)

- [x] PR author has checked that all the criteria below are met
- The PR description includes an overview of the change
- The PR description articulates the motivation for the change
- The change includes tests OR the PR description describes a testing
strategy
- The PR description notes risks associated with the change, if any
- Newly-added code is easy to change
- The change follows the [library release note
guidelines](https://ddtrace.readthedocs.io/en/stable/releasenotes.html)
- The change includes or references documentation updates if necessary
- Backport labels are set (if
[applicable](https://ddtrace.readthedocs.io/en/latest/contributing.html#backporting))

- [x] Reviewer has checked that all the criteria below are met
- Title is accurate
- All changes are related to the pull request's stated goal
- Avoids breaking
[API](https://ddtrace.readthedocs.io/en/stable/versioning.html#interfaces)
changes
- Testing strategy adequately addresses listed risks
- Newly-added code is easy to change
- Release note makes sense to a user of the library
- If necessary, author has acknowledged and discussed the performance
implications of this PR as reported in the benchmarks PR comment
- Backport labels are set in a manner that is consistent with the
[release branch maintenance
policy](https://ddtrace.readthedocs.io/en/latest/contributing.html#backporting)

[APPSEC-57414]:
https://datadoghq.atlassian.net/browse/APPSEC-57414?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ

(cherry picked from commit 20a96bb)
smola added a commit that referenced this pull request May 7, 2025
Current stacktrace filtering code returned no location if all frames are
outside the current working directory or in site-packages. This often
happens in the following scenarios:
- asyncio code: the full stacktrace may be in site-packages, outside app
directory.
- running applications installed in site-packages.

In these cases, vulnerabilities were being dropped. The fix includes:
- First, the first frame that is not a frozen package (or `<template>`
or anything starting with `<`), and not in the stdlib path (but
potentially in the purelib path) is found and saved as a backup frame,
if any. If none is found, no location is returned.
- From there, the first frame that is not a frozen package, not in the
stdlib path, and not in the purelib path is checked. If found, that
location is returned. Otherwise, the backup frame is returned.
- Code to relativize path to the vulnerability location is now extended
to account for the fact that we can return paths within the purelib
path.

In practice, this means that vulnerabilities found in site-packages,
with no other relevant frame, will be reported.

[APPSEC-57414](https://datadoghq.atlassian.net/browse/APPSEC-57414)

(cherry picked from commit 20a96bb)
smola added a commit that referenced this pull request May 7, 2025
Current stacktrace filtering code returned no location if all frames are
outside the current working directory or in site-packages. This often
happens in the following scenarios:
- asyncio code: the full stacktrace may be in site-packages, outside app
directory.
- running applications installed in site-packages.

In these cases, vulnerabilities were being dropped. The fix includes:
- First, the first frame that is not a frozen package (or `<template>`
or anything starting with `<`), and not in the stdlib path (but
potentially in the purelib path) is found and saved as a backup frame,
if any. If none is found, no location is returned.
- From there, the first frame that is not a frozen package, not in the
stdlib path, and not in the purelib path is checked. If found, that
location is returned. Otherwise, the backup frame is returned.
- Code to relativize path to the vulnerability location is now extended
to account for the fact that we can return paths within the purelib
path.

In practice, this means that vulnerabilities found in site-packages,
with no other relevant frame, will be reported.

[APPSEC-57414](https://datadoghq.atlassian.net/browse/APPSEC-57414)

(cherry picked from commit 20a96bb)
smola added a commit that referenced this pull request May 7, 2025
Follow up to #13272:

- Avoid an exception when no relevant frame is found, return a tuple of
`None` objects instead. This was a regression in #13272.
smola added a commit that referenced this pull request May 7, 2025
Follow up to #13272:

- Avoid an exception when no relevant frame is found, return a tuple of
`None` objects instead. This was a regression in #13272.

(cherry picked from commit 2e2cb67)
smola added a commit that referenced this pull request May 12, 2025
Follow up to #13272:

- Avoid an exception when no relevant frame is found, return a tuple of
`None` objects instead. This was a regression in #13272.

(cherry picked from commit 2e2cb67)
smola added a commit that referenced this pull request May 12, 2025
Follow up to #13272:

- Avoid an exception when no relevant frame is found, return a tuple of
`None` objects instead. This was a regression in #13272.

(cherry picked from commit 2e2cb67)
smola added a commit that referenced this pull request May 12, 2025
Follow up to #13272:

- Avoid an exception when no relevant frame is found, return a tuple of
`None` objects instead. This was a regression in #13272.

(cherry picked from commit 2e2cb67)
smola added a commit that referenced this pull request May 13, 2025
Follow up to #13272:

- Avoid an exception when no relevant frame is found, return a tuple of
`None` objects instead. This was a regression in #13272.

(cherry picked from commit 2e2cb67)
smola added a commit that referenced this pull request May 13, 2025
Follow up to #13272:

- Avoid an exception when no relevant frame is found, return a tuple of
`None` objects instead. This was a regression in #13272.

(cherry picked from commit 2e2cb67)
smola added a commit that referenced this pull request May 13, 2025
Follow up to #13272:

- Avoid an exception when no relevant frame is found, return a tuple of
`None` objects instead. This was a regression in #13272.

(cherry picked from commit 2e2cb67)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

ASM Application Security Monitoring backport 2.21

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants