Il 2023-08-18 09:22 Omar Polo ha scritto:
> On 2023/08/18 02:06:11 +0000, whistlez <whistlez...@riseup.net> wrote:
>> Il 2023-08-18 02:20 Scott Cheloha ha scritto:
>> >> On Aug 17, 2023, at 10:28, whistlez <whistlez...@riseup.net> wrote:
>>
>> 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.
>
> Assuming that the kernel was compromised, how can you trust a tool to
> detect that? The compromised kernel could return normal-looking data
> through /dev/{k,}mem (ignoring for a moment the perils of allowing
> random software to access these devices.) You'd be asking a liar if
> they're telling the truth :)
Yes, I understand exactly what you're saying, and I partly agree, but
I'd like to share some thoughts. However, first and foremost, I want to
reiterate that I'm not a developer, and for this reason, my statements
might be based on entirely erroneous assumptions. But let's get to the
considerations.
1. Volatility allows the detection of hidden kernel modules in a Linux
environment, including typical LKM rootkits.
2. There are multiple methods for RAM dumping, some of which cannot be
circumvented and do not require specific software or interfaces. For
example:
a. Through a 'cold boot attack,' it's possible to dump RAM from an
uncompromised operating system. (Reference:
https://en.wikipedia.org/wiki/Cold_boot_attack)
b. Through a DMA attack, leveraging FireWire or other hardware
interfaces, it's possible to dump RAM. I believe that, in this case, as
in the previous one, the kernel would be completely unaware. An example
of this kind of attack and dump is "inception"
(https://github.com/carmaa/inception).
c. In a virtualized environment such as VMM, VirtualBox, VMware,
etc. (we know OpenBSD can be virtualized), you can acquire RAM without
the operating system knowing.
3. The third consideration relates to what you said – that it doesn't
make sense to ask a liar if he is lying. I think, similar to how the
police operate, you can ask a suspect a series of questions, and all
answers should exhibit a certain logical consistency. If you want to
make a neighborhood disappear from a city, you can't just dig a hole.
Because everyone will understand that it can't be true. Roads will
terminate at the hole and continue on the other side, and that doesn't
make sense. Moral of the story: the more you have to hide, the more code
you have to write to make your façade believable. And so, the more
questions you ask the suspect, the more they have to invent lies that
are consistent. The more lies there are, the greater the chances of
creating a discrepancy in the infrastructure. For instance, library,
memory, pointers must be reorganized coherently. You can't make a
pointer point to a memory area that is empty.
4. Another thing we can't ignore is that we all know there are no
definitive security solutions, only building bricks that add layers of
difficulty and complicate matters for an attacker. Keeping hidden code
within a kernel while simultaneously ensuring that code performs actions
is an additional layer of difficulty.
