Re: volatility or something like that in the future ?
> You asked for others to do things you want. But we don't want the feature > you want, because we consider it an anti-feature. > > We do not want to expose the kernel address space contents like you > want, because it contains secrets information which is used for a wide > variety of attach surfaces. Secrets does not mean passwords, it means > contents and layout of objects an attacker will use. > Thank you, this was the answer I was crying and stomping my feet for. > What you ask for is the opposite of what we would do. > > We won't do it. We don't want code that does it (not that you have any > code which does it). > > And that is the end of story. ok, thanks.
Re: volatility or something like that in the future ?
>> >> Thanks for your reply, but my emails didn't received the replies I >> expected to have. >> And to be honest I don't want to plunge into arid controversy. >> > > This is not hate, BUT you are acting like a baby. > > 'Whaa wha you didn't do what I wanted' Well, that's certainly an adult-like response. In fact, adults usually mimic children.
Re: volatility or something like that in the future ?
whistlez wrote: > My mindset was to contribute what I know to improve the > project. What did you contribute? You typed words, which is not a contribution. You asked for others to do things you want. But we don't want the feature you want, because we consider it an anti-feature. We do not want to expose the kernel address space contents like you want, because it contains secrets information which is used for a wide variety of attach surfaces. Secrets does not mean passwords, it means contents and layout of objects an attacker will use. What you ask for is the opposite of what we would do. We won't do it. We don't want code that does it (not that you have any code which does it). And that is the end of story.
Re: volatility or something like that in the future ?
> > You are spending a lot of time telling very skilled people that > you are both ignorant on this topic AND how to do their jobs. > I understand what you're saying, even though I'm not entirely sure things are as you describe. However, it already seems important to me that I managed to understand because, honestly, I didn't think I had been offensive. My mindset was to contribute what I know to improve the project. But you're absolutely right; being quite ignorant, my attempts to contribute might come across as unpleasant or even offensive. However, I usually don't respond in kind if someone offends me. Furthermore, the underlying question of my message was, how do I check the kernel's integrity? And my suggestions were a response to this underlying question. Honestly, it doesn't seem offensive to me to ask a question. But evidently, I'm mistaken. Perhaps someone believes that the question is actually rhetorical and aimed at criticizing the entire project. But as far as I'm concerned, it's not. > You know what is offensive around here? > * Telling developers how they should spend their efforts. > * Being offended when someone suggests YOU demonstrate work. > * Taking pride in your ignorance on how to do something but > assuming you have the right to tell others to utilize their > skill. > * Suggesting that because Linux does something, OpenBSD should > do it without understanding how WRONG so much of Linux is (at > least in an OpenBSD mindset). > > Linux has become Windows Reinvented Badly. You seem to think > OpenBSD should become Linux Reinvented Badly. That's offensive. These religious wars honestly seem prehistoric to me. Very much akin to football fanatics or political squabbles, I found them tiresome in the late '90s, and now I just can't stomach them. Moral judgments about reality don't solve problems, because the problems remain despite how much you might express that they are ugly and bad. As for the rest, I apologize if I have been offensive. I didn't think I was, but indeed my presumption can be unsettling. I understand that now. I apologize.
Re: volatility or something like that in the future ?
Nick Holland writes: > Linux has become Windows Reinvented Badly. You seem to think > OpenBSD should become Linux Reinvented Badly. That's offensive. We prefer Unix Reimplemented... Matthew (Just kidding; it's great)
Re: volatility or something like that in the future ?
On 2023年08月20日 01:27, lain. wrote: > And to respond to whistlez/diana: My apologies for that, I said "whistlez/diana" by error. What I meant is just "whistlez".
Re: volatility or something like that in the future ?
On 2023年08月19日 09:36, Theo de Raadt wrote: > This is not hate, BUT you are acting like a baby. > > 'Whaa wha you didn't do what I wanted' This is what I love about OpenBSD, it's one of the last few OS's that is still capable of resisting the pressure by the status quo, whereas everybody else has bent the knee a long time ago. And to respond to whistlez/diana: Unlike many others, OpenBSD is made by the people who use their stuff themselves, and just make it available to everybody else for free. This does not entitle you to make demands. Since OpenBSD devs are hackers, you as the OpenBSD user are expected to have a hacker mentality too. Want Python in OpenBSD? Just install it then, it's only 1 command away! Want to see a plugin for a Python script in OpenBSD? Make one yourself! I too had to get my shit to work on OpenBSD by myself, and eventually ask how to do it as a last resort. For example, I program in Zig a lot, and Zig requires LLVM 16 or newer in order to compile the Zig compiler, OpenBSD only ships with LLVM 13, and because of this, the Zig compiler is extremely outdated too. The other option is to wait a few more years for Zig 1.0 to release, and then cross-compile the Zig compiler for OpenBSD from Linux like a real clown. But I don't nag the devs to hold my hand and do something they will probably say "no" to anyway, instead I'm trying to figure out how to do so myself, and maybe contribute to the ports tree if I finally get it to work, and write documentation so I know how to do it next time. -- lain.
Re: volatility or something like that in the future ?
On 8/19/23 06:05, whistlez wrote: ... I honestly don't understand this hatred. ... Dude, for a self-proclaimed sensitive person, you are really very offensive, and begging to have your tender little ass handed (verbally) to you on a platter. You are spending a lot of time telling very skilled people that you are both ignorant on this topic AND how to do their jobs. You know what is offensive around here? * Telling developers how they should spend their efforts. * Being offended when someone suggests YOU demonstrate work. * Taking pride in your ignorance on how to do something but assuming you have the right to tell others to utilize their skill. * Suggesting that because Linux does something, OpenBSD should do it without understanding how WRONG so much of Linux is (at least in an OpenBSD mindset). Linux has become Windows Reinvented Badly. You seem to think OpenBSD should become Linux Reinvented Badly. That's offensive. Nick.
Re: volatility or something like that in the future ?
whistlez wrote: > > > > I saw no hatred in the post you replied to. > > > > OpenBSD developers are Makers, not Takers. They code for OpenBSD for > > themselves, not for the user community. > > > > The point is you should spend some time trying to contribute before you > > start asking for some "feature". > > > > I've been a user for 25 years and really appreciate all the work the > > developers have done during that time. In that time I've also contributed > > a very microscopic bit of bug fixes. > > > > diana > > > > Thanks for your reply, but my emails didn't received the replies I > expected to have. > And to be honest I don't want to plunge into arid controversy. > This is not hate, BUT you are acting like a baby. 'Whaa wha you didn't do what I wanted'
Re: volatility or something like that in the future ?
> > I don't see any hatred here. I think they understood the question just fine. > I think perhaps you might be asking in the wrong place for > voulenteers to write software for Volatility -- this is an OpenBSD list. Yes, probably I missed that point. I'm sorry I didnt' understand for that question I'd ask elsewhere. Thanks and I'm sorry.
Re: volatility or something like that in the future ?
> I saw no hatred in the post you replied to. > > OpenBSD developers are Makers, not Takers. They code for OpenBSD for > themselves, not for the user community. > > The point is you should spend some time trying to contribute before you start > asking for some "feature". > > I've been a user for 25 years and really appreciate all the work the > developers have done during that time. In that time I've also contributed a > very microscopic bit of bug fixes. > > diana > Thanks for your reply, but my emails didn't received the replies I expected to have. And to be honest I don't want to plunge into arid controversy.
Re: volatility or something like that in the future ?
On Sat, Aug 19, 2023 at 10:05:41AM +, whistlez said: I honestly don't understand this hatred. I call it that because I refuse to accept that you didn't understand the question. Volatility has no plugin to interpret a ram dump on openbsd and so having only the dump is totally useless. If you really don't understand I'll paste the volatility help to show you that there are no plugins for openbsd but only for linux, windows and mac. I don't see any hatred here. I think they understood the question just fine. I think perhaps you might be asking in the wrong place for voulenteers to write software for Volatility -- this is an OpenBSD list. -- Please direct replies to the list.
Re: volatility or something like that in the future ?
I saw no hatred in the post you replied to.
OpenBSD developers are Makers, not Takers. They code for OpenBSD for
themselves, not for the user community.
The point is you should spend some time trying to contribute before you start
asking for some "feature".
I've been a user for 25 years and really appreciate all the work the developers
have done during that time. In that time I've also contributed a very
microscopic bit of bug fixes.
diana
On August 19, 2023 4:05:41 AM MDT, whistlez wrote:
>Il 2023-08-18 19:42 Mike Larkin ha scritto:
>I honestly don't understand this hatred. I call it that because I refuse
>to accept that you didn't understand the question. Volatility has no
>plugin to interpret a ram dump on openbsd and so having only the dump is
>totally useless. If you really don't understand I'll paste the
>volatility help to show you that there are no plugins for openbsd but
>only for linux, windows and mac.
>
>$ vol --help
>Volatility 3 Framework 1.0.0-beta.1
>usage: volatility [-h] [-c CONFIG] [--parallelism
>[{processes,threads,off}]] [-e EXTEND] [-p PLUGIN_DIRS] [-s SYMBOL_DIRS]
>[-v] [-l LOG] [-o OUTPUT_DIR] [-q]
> [-r RENDERER] [-f FILE] [--write-config]
>[--clear-cache] [--single-location SINGLE_LOCATION]
>[--single-swap-locations SINGLE_SWAP_LOCATIONS]
> plugin ...
>
>An open-source memory forensics framework
>
>optional arguments:
> -h, --helpshow this help message and exit
> -c CONFIG, --config CONFIG
>Load the configuration from a json file
> --parallelism [{processes,threads,off}]
>Enables parallelism (defaults to processes if no
>argument given)
> -e EXTEND, --extend EXTEND
>Extend the configuration with a new (or changed)
>setting
> -p PLUGIN_DIRS, --plugin-dirs PLUGIN_DIRS
>Semi-colon separated list of paths to find
>plugins
> -s SYMBOL_DIRS, --symbol-dirs SYMBOL_DIRS
>Semi-colon separated list of paths to find
>symbols
> -v, --verbosity Increase output verbosity
> -l LOG, --log LOG Log output to a file as well as the console
> -o OUTPUT_DIR, --output-dir OUTPUT_DIR
>Directory in which to output any generated files
> -q, --quiet Remove progress feedback
> -r RENDERER, --renderer RENDERER
>Determines how to render the output (quick, csv,
>pretty, json, jsonl)
> -f FILE, --file FILE Shorthand for --single-location=file:// if
>single-location is not defined
> --write-configWrite configuration JSON file out to config.json
> --clear-cache Clears out all short-term cached items
> --single-location SINGLE_LOCATION
>Specifies a base location on which to stack
> --single-swap-locations SINGLE_SWAP_LOCATIONS
>Specifies a list of swap layer URIs for use with
>single-location
>
>Plugins:
> plugin
>configwriter.ConfigWriter
>Runs the automagics and both prints and outputs
>configuration in the output directory.
>frameworkinfo.FrameworkInfo
>Plugin to list the various modular components of
>Volatility
>layerwriter.LayerWriter
>Runs the automagics and writes out the primary
>layer produced by the stacker.
>linux.bash.Bash Recovers bash command history from memory.
>linux.check_afinfo.Check_afinfo
>Verifies the operation function pointers of
>network protocols.
>linux.check_syscall.Check_syscall
>Check system call table for hooks.
>linux.elfs.Elfs Lists all memory mapped ELF files for all
>processes.
>linux.lsmod.Lsmod Lists loaded kernel modules.
>linux.lsof.Lsof Lists all memory maps for all processes.
>linux.malfind.Malfind
>Lists process memory ranges that potentially
>contain injected code.
>linux.proc.Maps Lists all memory maps for all processes.
>linux.pslist.PsList
>Lists the processes present in a particular
>linux memory image.
>linux.pstree.PsTree
>Plugin for listing processes in a tree based on
>their parent process ID.
>mac.bash.Bash Recovers bash command history from memory.
>mac.check_syscall.Check_syscall
>Check system call table for hooks.
>mac.check_sysctl.Check_sysctl
>Check sysctl handlers for hooks.
>mac.check_trap_table.Check_trap_table
>Check mach trap table for hooks.
>mac.ifconfig.Ifconfig
>Lists loaded kernel modules
>mac.lsmod.Lsmod Lists loaded kernel modules.
>mac.lsof.lsof Lists all open file descriptors for all
>processes.
>mac.malfind.Malfind
>Lists process memory ranges that potentially
>contain injected code.
>mac.n
Re: volatility or something like that in the future ?
Hey, Am 19.08.2023 um 12:05 schrieb whistlez: I honestly don't understand this hatred. I call it that because I refuse to accept that you didn't understand the question. Volatility has no plugin to interpret a ram dump on openbsd and so having only the dump is totally useless. If you really don't understand I'll paste the volatility help to show you that there are no plugins for openbsd but only for linux, windows and mac. just a simply suggestion here, as far as i can see this Tool/Application is written in python so as mention before make your own plugin then? Python should be available on openBSD, you can use the tools to dump information, you can start asking people who got a clue to interpret the dump to give you hints and pointers and then simply display it in your plugin as you please. That said you need of course to put in the effort to write the plugin and if you cant do it you might wanna as on github if people who can are willing to do the work mentioned above. At that point you might get your plugin done. And as clarification, I dont write that without any hatred just as a observer of the past few mails. Cheers -- Before you write me an email ... have you tried switching it off and on again ? Markus Rosjatfon: +49 351 8107224mail: ros...@ghweb.de G+H Webservice GbR Gorzolla, Herrmann Königsbrücker Str. 70, 01099 Dresden http://www.ghweb.de fon: +49 351 8107220 fax: +49 351 8107227
Re: volatility or something like that in the future ?
Hello, On Sat, Aug 19, 2023 at 12:05:41PM +0200, whistlez wrote: > I honestly don't understand this hatred. I call it that because I refuse > to accept that you didn't understand the question. Volatility has no > plugin to interpret a ram dump on openbsd and so having only the dump is > totally useless. If you really don't understand I'll paste the > volatility help to show you that there are no plugins for openbsd but > only for linux, windows and mac. there is nothing in openbsd that needs to change for a dump _analysis_ plugin. The only part relevant to openbsd is how to get the dump and that part has been satisfactorily solved, as far as I can tell. You can proceed to write your plugin now. M. -- id' Ash = Ash; id' Dust = Dust; id' _ = undefined
Re: volatility or something like that in the future ?
Il 2023-08-18 19:42 Mike Larkin ha scritto:
> On Fri, Aug 18, 2023 at 01:31:41PM +, whistlez wrote:
>> Il 2023-08-18 09:22 Omar Polo ha scritto:
>> > On 2023/08/18 02:06:11 +, whistlez wrote:
>> >> Il 2023-08-18 02:20 Scott Cheloha ha scritto:
>>
>> 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.
>
I honestly don't understand this hatred. I call it that because I refuse
to accept that you didn't understand the question. Volatility has no
plugin to interpret a ram dump on openbsd and so having only the dump is
totally useless. If you really don't understand I'll paste the
volatility help to show you that there are no plugins for openbsd but
only for linux, windows and mac.
$ vol --help
Volatility 3 Framework 1.0.0-beta.1
usage: volatility [-h] [-c CONFIG] [--parallelism
[{processes,threads,off}]] [-e EXTEND] [-p PLUGIN_DIRS] [-s SYMBOL_DIRS]
[-v] [-l LOG] [-o OUTPUT_DIR] [-q]
[-r RENDERER] [-f FILE] [--write-config]
[--clear-cache] [--single-location SINGLE_LOCATION]
[--single-swap-locations SINGLE_SWAP_LOCATIONS]
plugin ...
An open-source memory forensics framework
optional arguments:
-h, --helpshow this help message and exit
-c CONFIG, --config CONFIG
Load the configuration from a json file
--parallelism [{processes,threads,off}]
Enables parallelism (defaults to processes if no
argument given)
-e EXTEND, --extend EXTEND
Extend the configuration with a new (or changed)
setting
-p PLUGIN_DIRS, --plugin-dirs PLUGIN_DIRS
Semi-colon separated list of paths to find
plugins
-s SYMBOL_DIRS, --symbol-dirs SYMBOL_DIRS
Semi-colon separated list of paths to find
symbols
-v, --verbosity Increase output verbosity
-l LOG, --log LOG Log output to a file as well as the console
-o OUTPUT_DIR, --output-dir OUTPUT_DIR
Directory in which to output any generated files
-q, --quiet Remove progress feedback
-r RENDERER, --renderer RENDERER
Determines how to render the output (quick, csv,
pretty, json, jsonl)
-f FILE, --file FILE Shorthand for --single-location=file:// if
single-location is not defined
--write-configWrite configuration JSON file out to config.json
--clear-cache Clears out all short-term cached items
--single-location SINGLE_LOCATION
Specifies a base location on which to stack
--single-swap-locations SINGLE_SWAP_LOCATIONS
Specifies a list of swap layer URIs for use with
single-location
Plugins:
plugin
configwriter.ConfigWriter
Runs the automagics and both prints and outputs
configuration in the output directory.
frameworkinfo.FrameworkInfo
Plugin to list the various modular components of
Volatility
layerwriter.LayerWriter
Runs the automagics and writes out the primary
layer produced by the stacker.
linux.bash.Bash Recovers bash command history from memory.
linux.check_afinfo.Check_afinfo
Verifies the operation function pointers of
network protocols.
linux.check_syscall.Check_syscall
Check system call table for hooks.
linux.elfs.Elfs Lists all memory mapped ELF files for all
processes.
linux.lsmod.Lsmod Lists loaded kernel modules.
linux.lsof.Lsof Lists all memory maps for all processes.
linux.malfind.Malfind
Lists process memory ranges that potentially
contain injected code.
linux.proc.Maps Lists all memory maps for all processes.
linux.pslist.PsList
Lists the processes present in a particular
linux memory image.
linux.pstree.PsTree
Plugin for listing processes in a tree based on
their parent process ID.
mac.bash.B
Re: volatility or something like that in the future ?
> >> Furthermore, in my opinion - brace yourself, I might trigger an atomic > >> war with what I'm about to say - Don't worry. OpenBSDs ministry of defence considered dropping atomic bombs over Australia in the past. It's considered an acceptable way of CVS conflict resolution. > 1. Volatility allows the detection of hidden kernel modules in a Linux > environment, including typical LKM rootkits. So, maybe don't use loadable kernel modules at all? Problem gone, nothing to detect here. > 2. There are multiple methods for RAM dumping, some of which cannot be > circumvented and do not require specific software or interfaces. I'm not a dev, but I do trust the devs handling that. Regarding the rest of your reasoning, I think you are way off-track. Linux assumptions do not apply.
Re: volatility or something like that in the future ?
On 2023-08-18, whistlez wrote: > > 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. I think it would be better to concentrate on the above methods. They don't rely on bypassing security measures in the OS (allowing /dev/mem from userland means you turn some possible attacks from "must subvert the kernel" to "must subvert root"), and sidestep the "can you trust the kernel" problem. -- Please keep replies on the mailing list.
Re: volatility or something like that in the future ?
On Fri, Aug 18, 2023 at 01:31:41PM +, whistlez wrote:
> Il 2023-08-18 09:22 Omar Polo ha scritto:
> > On 2023/08/18 02:06:11 +, whistlez wrote:
> >> Il 2023-08-18 02:20 Scott Cheloha ha scritto:
> >> >> On Aug 17, 2023, at 10:28, whistlez 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.
>
Re: volatility or something like that in the future ?
Il 2023-08-18 09:22 Omar Polo ha scritto:
> On 2023/08/18 02:06:11 +, whistlez wrote:
>> Il 2023-08-18 02:20 Scott Cheloha ha scritto:
>> >> On Aug 17, 2023, at 10:28, whistlez 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.
Re: volatility or something like that in the future ?
On Fri, Aug 18, 2023 at 2:22 AM Scott Cheloha wrote: > > > On Aug 17, 2023, at 10:28, whistlez wrote: > > > > [...] I believe we need to realize that, while the kernel is very > > secure, zero-day vulnerabilities are always a lurking threat. > > > > For those that don't know what is volatility, this is github page > > 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. Agreed. After reading their FAQ I still don't understand - it's most definitely a made-up FAQ of questions no one asked, but things they want to tell. One thing that sticks out to me is that they felt the need to make up their own custom license, the Volatility Software License. Doing something like that in 2019 seems a bit weird.
Re: volatility or something like that in the future ?
On 2023/08/18 02:06:11 +, whistlez wrote:
> Il 2023-08-18 02:20 Scott Cheloha ha scritto:
> >> On Aug 17, 2023, at 10:28, whistlez 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.
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 :)
Re: volatility or something like that in the future ?
Il 2023-08-18 02:20 Scott Cheloha ha scritto: >> On Aug 17, 2023, at 10:28, whistlez 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.
Re: volatility or something like that in the future ?
> On Aug 17, 2023, at 10:28, whistlez wrote: > > [...] I believe we need to realize that, while the kernel is very > secure, zero-day vulnerabilities are always a lurking threat. > > For those that don't know what is volatility, this is github page > 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.
Re: volatility or something like that in the future ?
Hi, On Thu, Aug 17, 2023 at 05:12:54PM +0200, whistlez wrote: > Hello community, I would like to ask if it's possible to develop a tool > similar to Volatility in the future or a specific integration for > OpenBSD. Along with a tool that can perform RAM dumping. do you need anything else than mem(4)? I.e. /dev/mem. See the manpage for more details. Yours, M. -- id' Ash = Ash; id' Dust = Dust; id' _ = undefined
volatility or something like that in the future ?
Hello community, I would like to ask if it's possible to develop a tool similar to Volatility in the future or a specific integration for OpenBSD. Along with a tool that can perform RAM dumping. However, could this potentially make the kernel vulnerable? In my opinion, even though I'm not a developer, it would be desirable to have a proper kernel interface for performing the dump. Something that is maintained directly by the development team to prevent the software team from constantly keeping up with changes in every new kernel release. I believe we need to realize that, while the kernel is very secure, zero-day vulnerabilities are always a lurking threat. For those that don't know what is volatility, this is github page https://github.com/volatilityfoundation/volatility3 I hope Theo doesn't get angry, as I'm a very sensitive person, and if someone offends me or makes fun of me, it really upsets me. regards WhistleX
