-
-
Notifications
You must be signed in to change notification settings - Fork 34
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
Confirm that 1.4.13 was not a security release? #38
Comments
Thanks @mrook! I've got a support ticket open with github about the mistaken advisory but not sure if/when that'll go anywhere. |
Hello, Guys. This is miner after delivering initiate compromised you data published on server, next step crypting you database and create blank table of one written text: Please pay bitcoin wallet for lost your crypted data from you database. |
Hi @vladxendev - I'm not sure what I'm looking at. Is this a log file? From what? An exploit? What "miner" are you talking about? |
Hi @mrook - I'm talking about exploiting the CVE-2020-36193 vulnerability, the fixes for which do not work in versions 1.4.12 / 1.4.13 / 1.4.14, since this vulnerability was exploited on my server where pear / Archive_Tar 1.4.14 is installed by the current latest version. |
Okay, understood. Can you explain how you are exploiting this, i.e. how our fixes might fail to defend against the exploit? |
I see the involvement of the CVE-2020-36193 vulnerability, which I encountered half a year ago, and I already had exactly the same consequences on my sites, I then manually installed at that time the version with the very first fix 1.4.12, and up to 18.12 .2021 I slept peacefully, but noticed in the server processes /tmp/kdevtmpfsi and /tmp/kinsing that load all the server processor cores to 100%, I immediately thought that maybe I forgot to install patch 1.4.12 somewhere, but after checking orb I found that it was installed everywhere and did not work, so how I found out in the logs what happened the last time half a year ago, I reinstalled the system and installed the fix 1.4.14, but a day later I found a newly appeared miner inside the docker container, traces of which, as an explanation, are in the log that I provided and that's all that I have. |
I see. It's hard to make any conclusions from your posted log, especially without knowing more context. What is in your /index.php for example? Can you share where you are using Archive_Tar in publicly accessible scripts? What archives are being unpacked? |
I do not use the tar archiver in my scripts, it is simply available in my Php environment and comes bundled by default as a built-in package or module, but judging by the logs, I see that it is being exploited by a post request using a call to "POST /usr/local/lib/php/PEAR.php" 200 and "POST /usr/local/lib/php/System.php" 200. |
As @mrook said, it's hard to conclude anything much from the details shared. However, to me this does not look related to the directory traversal vulnerabilities addressed in recent releases of Archive_Tar. It looks like perhaps you have a Remote Code Execution vulnerability somewhere and it's being exploited to run this: https://sysdig.com/blog/zoom-into-kinsing-kdevtmpfsi/ I am curious about requests to the path |
Indeed, I'm more than happy to help you (and if there's really something amiss with Archive_Tar, fix it) - but it's difficult to determine from what I've seen so far. |
GHSA-rpw6-9xfx-jvcx
...suggests that 1.4.13 included a new security fix for CVE-2020-28948.
It looks to me like #35 / #36 was a bugfix for a regression caused by the mitigation for
CVE-2020-28948
( cde4605 ), but I don't think it's a new security fix in itself.Could you please confirm either way @mrook? Thanks!
The text was updated successfully, but these errors were encountered: