pf can't redirect outgoing traffic to localhost
Hello,
I have sslsplit listening on 127.0.0.1 port 10443 and I want redirect
all my outgoing desktop web traffic to sslsplit, then localhost port
10443. SSLSPLIT is just a kind of transparent proxy but cannot be used
as a conventional proxy (set up on the browser config). Reading the
pf.conf man seems that there isn't a way to do that.
For example rdr-to does not support redirection to localhost.
man:
rdr-to is usually applied inbound. If applied outbound, rdr-to to a
local IP address is not supported.
Divert-to does not support outgoing traffic ("pass out" or "match out").
Also I tried to make an IF alias like this
ifconfig em0 inet 192.168.0.6 255.255.255.0
ifconfig em0 inet alias 192.168.0.7 255.255.255.0
my gw is 192.168.0.1
I put listening the sslsplit on 192.168.0.7 (the alias) port 10443 and I
make a pf rule like this:
pass out log on em0 proto tcp from 192.168.0.6 to port 443 rdr-to
192.168.0.7 port 10443
pass out log on em0 proto tcp from 192.168.0.6 to port 80 rdr-to
192.168.0.7 port 10080
even this does not work... I suspect that even 192.168.0.7 is local ip.
Any help ?
7.5 problems with browser video and audio, part 2
Hello I write again about the following sent mail to misc: https://marc.info/?l=openbsd-misc=171260331305047=2 I use the link to the archive because I deleted all the mailing list mails then I can'f do a follow up. Anyway I have some news. If I run sndiod as my user with the following: $ sndiod -dd the browsers audio (firefox, chromium, ungoogled-chromium and iridium) works for about 10-15 seconds. After that it stops to work. The following are the logs: snd0: rec hw xrun, rused = 6720/7680 snd0: play hw xrun, pused = 960/7680 snd0: watchdog timeout firefox0: detached at -7200 + 0/480 snd0: software master level control enabled 0/output.level=127 at 6 -> dev_master:0: added 0/output.level=127 at 6 -> dev_master:0: removed The error seems: snd0: watchdog timeout If I run sndiod as user like the following (with -m play): $ sndiod -m play works very well. With ps aux | grep sndiod ti say that the process run as my user. If I run the rc script the process take the defaul user permission: _sndiop and _sndio with these permessions the audio doesn't work neither for few seconds. Other userful info: # audioctl name=auich0 mode= pause=1 active=0 nblks=16 blksz=480 rate=48000 encoding=s16le play.channels=2 play.bytes=0 play.errors=0 record.channels=2 record.bytes=0 record.errors=0 # ls -l /dev/audi* crw-rw 1 root wheel 42, 0 Apr 10 20:08 /dev/audio0 crw-rw 1 root wheel 42, 1 Apr 7 17:34 /dev/audio1 crw-rw 1 root wheel 42, 2 Apr 7 17:34 /dev/audio2 crw-rw 1 root wheel 42, 3 Apr 7 17:34 /dev/audio3 crw-rw 1 root wheel 42, 192 Apr 7 17:34 /dev/audioctl0 crw-rw 1 root wheel 42, 193 Apr 7 17:34 /dev/audioctl1 crw-rw 1 root wheel 42, 194 Apr 7 17:34 /dev/audioctl2 crw-rw 1 root wheel 42, 195 Apr 7 17:34 /dev/audioctl3 Thus it seems a permission problem. But as I already said If I run "mpv my_video.mp4" audio works even with the default permission but now with browsers. Hope this is useful. Thanks all. Have a nice day. W.
7.5 problems with browser video and audio
Hello, after upgrade to 7.5 (from 7.4) I have problems with all type of videos on all chromium flavor (ungoogled-chromium and iridium). Going in details the problem doesn't concern only youtube but all the videos in all websites. But some videos work. For example youtube shorts. But on all videos does not work. I tried to uninstall and reinstall two or three dozen of packages linked to the browser but I haven't solved the problem. I have the same problem with firefox. But if I play a video with "mpv video.mp4" it works very well, also the audio works. So it seems something linked to the browsers. The following is the log if I run a chromium session and I play a random video on yt: [80102:471841344:0408/172622.858323:ERROR:bus.cc(407)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix") [80102:471841344:0408/172622.858491:ERROR:bus.cc(407)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix") [80102:471841344:0408/172622.858540:ERROR:bus.cc(407)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix") [80102:471841344:0408/172622.858617:ERROR:bus.cc(407)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix") [80102:1069694880:0408/172622.913110:ERROR:policy_logger.cc(157)] :components/enterprise/browser/controller/chrome_browser_cloud_management_controller.cc(161) Cloud management controller initialization aborted as CBCM is not enabled. Please use the `--enable-chrome-browser-cloud-management` command line flag to enable it if you are not using the official Google Chrome build. [80102:471841344:0408/172623.027251:ERROR:bus.cc(407)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix") [80102:471841344:0408/172623.027532:ERROR:bus.cc(407)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix") [80102:-403990976:0408/172623.202595:ERROR:bus.cc(407)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix") [80102:471841344:0408/172623.290231:ERROR:bus.cc(407)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix") [80102:471841344:0408/172623.290334:ERROR:bus.cc(407)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix") [53057:-337215584:0408/172623.654661:ERROR:viz_main_impl.cc(196)] Exiting GPU process due to errors during initialization [80102:1069694880:0408/172624.173294:ERROR:object_proxy.cc(576)] Failed to call method: org.freedesktop.DBus.NameHasOwner: object_path= /org/freedesktop/DBus: unknown error type: [80102:1569613376:0408/172624.173820:ERROR:bus.cc(407)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix") [80102:471835200:0408/172624.519144:ERROR:object_proxy.cc(576)] Failed to call method: org.freedesktop.DBus.Properties.Get: object_path= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files [80102:471835200:0408/172624.520532:ERROR:object_proxy.cc(576)] Failed to call method: org.freedesktop.UPower.GetDisplayDevice: object_path= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files [80102:471835200:0408/172624.522130:ERROR:object_proxy.cc(576)] Failed to call method: org.freedesktop.UPower.EnumerateDevices: object_path= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files [80102:1069694880:0408/172624.570929:ERROR:object_proxy.cc(576)] Failed to call method: org.freedesktop.DBus.NameHasOwner: object_path= /org/freedesktop/DBus: unknown error type: [80102:-403991488:0408/172624.571398:ERROR:bus.cc(407)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix") [80102:1069694880:0408/172624.638201:ERROR:object_proxy.cc(576)] Failed to call method: org.freedesktop.DBus.NameHasOwner: object_path= /org/freedesktop/DBus: unknown error type: [80102:-403991488:0408/172624.638367:ERROR:bus.cc(407)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix") [80102:1069694880:0408/172624.665200:ERROR:object_proxy.cc(576)] Failed to call method:
Re: TLS handshake failure at pkg_update
Il 2024-04-08 09:14 Mizsei Zoltán ha scritto: > Hi, > vps$ doas pkg_add micro > https://cloudflare.cdn.openbsd.org/pub/OpenBSD/7.5/packages-stable/amd64/: > TLS handshake failure: handshake failed: error:02FFF00D:system > library:func(4095):Permission denied > https://cloudflare.cdn.openbsd.org/pub/OpenBSD/7.5/packages/amd64/: TLS > handshake failure: handshake failed: error:02FFF00D:system > library:func(4095):Permission denied > https://cloudflare.cdn.openbsd.org/pub/OpenBSD/7.5/packages/amd64/: empty > Can't find micro I had this problem in the past and usually means that your clock is not synchronized. Maybe you stopped ntpd ?
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 ?
> > 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 ?
> > 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 ?
Il 2023-08-18 19:42 Mike Larkin ha scritto:
> 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 +, 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 pre
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 +0000, 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 ?
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.
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
Re: iwm wifi driver errors
On Sun, Mar 15, 2020 at 02:15:36PM +, b...@0x1bi.net wrote: > Have you installed the wireless firmware? > http://firmware.openbsd.org/firmware/ > yeah of course without the firmware the interface doesn't work, and now I'm using the wifi.
iwm wifi driver errors
Hi, I found the following error in the logs about the wifi driver iwm: iwm0: could not remove binding (error 35) iwm0: fatal firmware error iwm0: could not remove binding (error 35) iwm0: could not remove binding (error 35) iwm0: failed to update MAC iwm0: could not add MAC context (error 35) iwm0: could not abort background scan iwm0: could not remove STA (error 35) iwm0: could not remove STA (error 35) iwm0: could not update PHY context (error 35) iwm0: could not add binding (error 35) iwm0: fatal firmware error Anyone knows what means ? thanks
Re: Hardening browser
On Thu, Mar 05, 2020 at 07:32:36AM -0700, Luke A. Call wrote: > On 03-05 04:18, Tomasz Rola wrote: > > On Wed, Mar 04, 2020 at 02:06:40AM +0100, whistlez...@riseup.net wrote: > > > Hi, > > > in the following message: > > > https://marc.info/?l=openbsd-misc=158110613210895=2 > > > Theo discourages to use unveil instead of chroot. > > > I asked if he suggests the same for the browser but he asked that chroot > > > is onlye for *root*. > > > Then what should I do to hardening the most exposed piece of code that > > > we use everyday ? > > > Now I'm using unveil+chrome... > > > Thank you. > > [] > > As of me, I use the trick with multiple users for different roles > > (similar to other person who posted in this thread). I also employ > > noscript in some of the roles. > > I just leave javascript off for usual browsing, with a tab sitting open > in chromium or iridium to turn it on for the occasional temporary need, > or added to the browser's exception list to allow permanently for > certain sites. This partly because it seems easy, and partly since I > probably won't know if a browser extension is sold to a malicious entity, or > otherwise compromised (so, seems a smaller attack surface, but still usually > convenient.) As I know many sites without js doesn't work. Anyway I don't understand how switching off js defend you from 0day browser bug. Maybe you mean that because many 0day concern javascript ?
Re: Hardening browser
On Wed, Mar 04, 2020 at 03:28:35PM +, Kevin Chadwick wrote: > On 2020-03-04 11:38, Ottavio Caruso wrote: > > Probably not what you were looking for but, back in the days when I > > was ultra paranoid about my web browsing, I used to use stripped down > > live usb installations of Linux distros (DSL was one of them that I > > remember). I ignore if OpenBSD comes with such a solution out the box, > > but I'm sure it wouldn't be difficult to make your own read-only > > install. Then, you could either reboot from it or run it through an > > emulator. > > A live cd is read-only and is also something I did for a while in my teenage > years. Knoppix, Insert were examples and STD was another aptly named one as it a read only cd don't give you any defense againt uefi rootkit > > However, considering OpenBSD replaces it's whole base every upgrade with > signed > binaries, then you get all of that for free. You can even double check the > bios > with flashrom (less so on laptops), bootloader, signing keys, packages etc., > if > you want to. > if your kernel is infected with uefi rootkit most probably double check uefi or bios with flashrom is absolutely not useful. > If this effort is really worth it, then it probably makes more sense than > trusting someone else to package up a usb linux distro or CD. > the problem is not trusting people that make package, the problem is the sites you visit.
Re: Hardening browser
On Wed, Mar 04, 2020 at 11:38:40AM +, Ottavio Caruso wrote: > On Wed, 4 Mar 2020 at 01:06, wrote: > > > > Hi, > > in the following message: > > https://marc.info/?l=openbsd-misc=158110613210895=2 > > Theo discourages to use unveil instead of chroot. > > I asked if he suggests the same for the browser but he asked that chroot > > Probably not what you were looking for but, back in the days when I > was ultra paranoid about my web browsing, I used to use stripped down > live usb installations of Linux distros (DSL was one of them that I > remember). I ignore if OpenBSD comes with such a solution out the box, > but I'm sure it wouldn't be difficult to make your own read-only > install. Then, you could either reboot from it or run it through an > emulator. > My opinion is that in the last 10 years the world of hackers groups was deeply changed. Deface or big worms that make big damages are not in fashion anymore. Today the hackers group want just only be as hidden as they can. Then today the biggest problems are the uefi/bios malware, if you use a read only live cd or usb don't stop someone infect your firmwares. And when you reboot your machine you are hacked. Maybe with an hypervisor that can isolate processes and kernels the job is more hard. One of the biggest criticism I make to openbsd is that the everyone processes are visible to everyone. So that if you use muliple account for multiple application you don't stop an infected process to see if you run a browser, a irc session and maybe what network you are connected, if you opened pdf, if you used vim for code and what code and so on. And the last but first for importance if you are sniffing your traffic to search a covert channel. If my browser is infected with a malware the first thing I do is try to sniff the traffic to detect strange destinations, but if the infected process can see if I'm running a sniffer all my investigations are absolutely unuseful. If a very skilled hacker exploit your browser, take the root and infect your uefi, you must trash your laptop. And of course if you discover it, because if someone infect your uefi most problably you will never know it!
Hardening browser
Hi, in the following message: https://marc.info/?l=openbsd-misc=158110613210895=2 Theo discourages to use unveil instead of chroot. I asked if he suggests the same for the browser but he asked that chroot is onlye for *root*. Then what should I do to hardening the most exposed piece of code that we use everyday ? Now I'm using unveil+chrome... Thank you.
6.6, X and braswell
Hi, I have the following bug: https://marc.info/?t=15636262941=1=2 now I'm on 6.5 and it works, but maybe one month ago I tried to install 6.6 and I found the bug. Anyone know if it was been resolved ? Thanks Whistlez
ffs details
Hi, I need some details about ffs, I read the kernel source but my c knowledge is very basic. I understood all about the superblock but my problem is understand how the files are allocated on the disk. Anyone could give me more details about files allocation ? Thank you.
Re: strange dmesg
On Mon, Feb 10, 2020 at 09:45:06AM -, Stuart Henderson wrote: > On 2020-02-10, Janne Johansson wrote: > > Den lör 8 feb. 2020 kl 11:31 skrev : > > > >> Hi, > >> I have some strange output from dmesg, what could be ? > >> At the follwoing link I've posted some screenshots: > >> https://postimg.cc/gallery/1o4wsaw74/ > >> > > > > dmesg is contained in a memory buffer with (hopefully) room for more than > > one dmesg, so you can get > > previous versions listed when you run it. If the memory gets slightly > > corrupted during reboots, > > I guess the "other" dmesgs can come out as garbage, based on how memory > > gets reused or > > reallocated in the time between reboot and next boot when the OS isn't in > > control of the > > RAM. > > From the contents, this one looks like it was probably overwritten with > some UEFI code during boot. > Could be a UEFI rootkit ? Or something that from UEFI try to inject code in the kernel ?
strange dmesg
Hi, I have some strange output from dmesg, what could be ? At the follwoing link I've posted some screenshots: https://postimg.cc/gallery/1o4wsaw74/ Thank you
Re: chroot vs unveil
On Thu, Feb 06, 2020 at 10:35:17AM -0700, Theo de Raadt wrote: > Kevin Chadwick wrote: > > > I am considering replacing all chroot use with unveil in my processes even > > where > > no filesystem access is required. > > I am discouraging this. > > unveil is a complicated mechanism, and we may still discover a bug in > it. > > Almost all the chroot in the tree are to empty unwriteable directories, > in which case chroot is very secure and a very simple mechanism. > you'd suggest the same for the browsers ? thank you
