On Fri, Aug 18, 2023 at 01:31:41PM +0000, whistlez wrote:
> 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.
Great, sounds like you've stumbled across 3 solutions for your problem.
Looks like no diff is needed after all.
>
> 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.
>
