vuln(NSWG-ECO-403): atob #211
Conversation
|
Citing my comment:
/cc @coolaj86 |
vuln/npm/403.json
Outdated
| "slug": "atob-out-of-bounds-read", | ||
| "recommendation": "update atob to 2.1.0 or higher", | ||
| "references": "- https://hackerone.com/reports/321686", | ||
| "cvss_vector": "CVSS:3.0/AV:P/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H", |
There was a problem hiding this comment.
AV:P seems incorrect. AC:H is better fit.
There was a problem hiding this comment.
do you thin AV is N? is this because you'd come up with a use-case where atob() is given a user input originated string?
Also, why AC: H? seems like the buffer vulnerability is of the same nature as others.
There was a problem hiding this comment.
@lirantal Should be the same as 309, 391, 392, 393.
Those do not require physical access. There is no reason for this to be AC:P.
AC:H because it's hard to actually reproduce this on real apps — attacker-supplied content should end up there, which requires playing around other logic. I.e. it's not just «feed input over http», it's «try to find where user input is fed to atob and attempt to supply a typed number there». It requires inpecting other components and, perhaps, bypassing them.
I.e. there are other things required to be passed for this to be exploited, this is not trivially exploitable.
Note: I also don't agree on AC:L (and A:N) for 309, but whatever.
|
@ChALkeR ping for my comment on the CVSS part |
|
@lirantal Will take a look today, thanks! |
|
Sorry, I've been slow. I'll update the engines property and republish. |
|
Published as atob@2.1.1 |
|
Ok, updated report. |
No description provided.