Il 2023-08-18 02:20 Scott Cheloha ha scritto: >> On Aug 17, 2023, at 10:28, whistlez <whistlez...@riseup.net> wrote: >>
>> https://github.com/volatilityfoundation/volatility3 > > What is the utility of this software? How > would supporting it benefit the project? > > I read the summary on Github. I am still > more or less completely in the dark on > why I or anyone would want to use it. It seems rather important to me because it's not possible to be certain about the invulnerability of the underlying operating system or the kernel. Alternatively, an attacker might have a zero-day exploit on Firefox or Chrome and inject code into the process, allowing data exfiltration. Even though the attacker would be confined within the jail created by the kernel, it doesn't seem acceptable to have unauthorized code running on one's machine, especially in a critical process like a browser. The same principle could be applied to another process more focused on firewall solutions, such as Snort. Furthermore, in my opinion - brace yourself, I might trigger an atomic war with what I'm about to say - we should consider it certain that the kernel could contain unknown vulnerabilities. Unauthorized code running in the kernel is impossible to detect, clearly. I'm talking about code that might not even reside on the disk but is injected remotely. Thus, the only way is through inspecting the RAM dump, that is, a software that can analyze the dump and determine its integrity. Additionally, due to kernel relinking, we know that its hash changes with every reboot, rendering classic integrity verification tools unusable. To put it simply, without delving into sophisticated attacks, a machine could be physically attacked, and unauthorized code could be introduced into the kernel. Therefore, we might end up with a machine compromised by a compromised kernel, and there might be no way (at least as far as I know) to know about it. This assumes there are unintentional vulnerabilities. But what if deliberate vulnerabilities are introduced? I recall an old piece of news, which I never understood if it was confirmed, that a developer of the OpenBSD kernel might have introduced a backdoor under instruction or through coercion by a security agency. Now, far be it from me to discredit the OpenBSD development team, which has done an enormous and exceptional job. It's clear that Theo has done, and is doing, a wonderful job... nevertheless, one should account for any eventuality. I believe that a forensics memory analysis interface would make persistence and invisibility of unauthorized code much harder to achieve. Even a developer intending to hide something would find themselves a bit more exposed. And all of this without even considering hardware vulnerabilities, such as those in CPUs or other aspects of the machine, like firmware.
