Offline syspatch
Greetings, We are experiencing extensive attacks including zero-click exploits with fileless malware from corrupted ISP/adversary, therefore, online system updating/upgrading is not possible. For the current release 7.5, specifically for security patches, if we downloaded the security patches located at any of the mirror links, for example, https://mirror.hs-esslingen.de/pub/OpenBSD/syspatch/7.5/amd64/ manually verified the signature with signify, then changed the online path under /etc/installurl to point to the usb/location that contains the downloaded security patch files, and then executed the command syspatch, usually, the security patch files gets pulled from the pointed physical location and gets updated, however, my question is, would that be sufficient for patching the system, or do we actually have to compile from source and include the security patch files in the compilation process?. We are applying the same process for firmware files, fw_update -p ./firmware_files Any suggestions to mitigate the zero-click exploit with fileless malware attacks. Please advise. In the firewall rules, one of the main purposes of block all rule is to make the attacker completely blind of the system being implemented, however, updating online completely defies the purpose of block all, because it helps a corrupted adversary monitoring the transmission figure out the server/site connecting to, in our case bsd, therefore, revealing the platform being implemented and lunching an attack targeted to that specific platform. Thank you for your kind support. John
Re: pf can't redirect outgoing traffic to localhost
Hello whistlez,
whistlez...@riseup.net (whistlez), 2024.06.20 (Thu) 02:49 (CEST):
> 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.
is the sslsplit transparent proxy running on the same machine on which
your web browsing happens? If the answer is yes, then PF simple rdr-to
will not work. The PF examples in sslsplit(1) clearly assume running on
the firewall. From cursory reading I'd play around with veb(4) if I were
you. Your locally generated traffic will only be outbound on your local
network interface and therefore rdr-to will not help. You need to find a
way to send the trafic on a detour over a virtual network interface,
where the traffic is inbound and can be rdr-to'ed.
If the answer is "no" and sslsplit transparent proxy is running on your
firewall, then just filter and redirect on the inbound interface, as the
examples in sslsplit(1) say.
Marcus
> 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 ?
Re: Offline syspatch
On Sat, Jun 29, 2024 at 9:30 AM jonathon575 wrote: > > Greetings, > > We are experiencing extensive attacks including zero-click exploits with > fileless malware from corrupted ISP/adversary, therefore, online system > updating/upgrading is not possible. > > For the current release 7.5, specifically for security patches, if we > downloaded the security patches located at any of the mirror links, for > example, > > https://mirror.hs-esslingen.de/pub/OpenBSD/syspatch/7.5/amd64/ > > manually verified the signature with signify, then changed the online path > under /etc/installurl to point to the usb/location that contains the > downloaded security patch files, and then executed the command syspatch, > usually, the security patch files gets pulled from the pointed physical > location and gets updated, however, my question is, would that be sufficient > for patching the system, or do we actually have to compile from source and > include the security patch files in the compilation process?. > > We are applying the same process for firmware files, fw_update -p > ./firmware_files > > Any suggestions to mitigate the zero-click exploit with fileless malware > attacks. Please advise. In the firewall rules, one of the main purposes of > block all rule is to make the attacker completely blind of the system being > implemented, however, updating online completely defies the purpose of block > all, because it helps a corrupted adversary monitoring the transmission > figure out the server/site connecting to, in our case bsd, therefore, > revealing the platform being implemented and lunching an attack targeted to > that specific platform. While the process of doing an offline sysupgrade is an interesting question as-is, I'm curious: what exactly do you mean by "exploits" here, and which patch do you think would solve the problem? I don't see anything serious that would be relevant to a headless server, and if you're claiming that an attacker can exploit your OpenBSD 7.5 server by doing some MITM on the wire then I think the developers would be very interested in hearing about the details!
Re: Offline syspatch
On Sat, Jun 29, 2024 at 01:42:15PM +0200, Anders Andersson wrote: > > Any suggestions to mitigate the zero-click exploit with fileless malware > > attacks. Please advise. In the firewall rules, one of the main purposes of > > block all rule is to make the attacker completely blind of the system being > > implemented, however, updating online completely defies the purpose of > > block all, because it helps a corrupted adversary monitoring the > > transmission figure out the server/site connecting to, in our case bsd, > > therefore, revealing the platform being implemented and lunching an attack > > targeted to that specific platform. > > While the process of doing an offline sysupgrade is an interesting > question as-is, I'm curious: what exactly do you mean by "exploits" > here, and which patch do you think would solve the problem? > > I don't see anything serious that would be relevant to a headless > server, and if you're claiming that an attacker can exploit your > OpenBSD 7.5 server by doing some MITM on the wire then I think the > developers would be very interested in hearing about the details! I also don't fully understand what the OP means. However the lead of this discussion I'd like to be part of, out of personal interest. It may be foolish to put 100% reliance on signify considering the looming threat of Quantum Computers being able to apply Shor's algorithm at some point in time. Does anyone here have leads as to how much time we have before this as Rodney Grimes in his book he authored with the title "cryptography apocalypse". I have this book still, I'm moving to .ca very soonish (3 weeks?), so that's when I won't have it anymore. Judging by whether I get a job in the Ottawa area before my travel money runs out, I'm destined to dissolve my apartment in .de in October. All this aside, just letting this wonderful community know what I'm doing and where I'm going, Some MIC circles may have interests in hijacking Open Source outlets, and things may get difficult fast. I'm interested in any plans, discussions worth contributing to, and insights in this threat on Open Source and particularily the free and open world approach and philosophy. Count me in to take note of everyones view point even if I don't re-contribute to this thread. Best Regards, -pjp -- ** all info about me: lynx https://callpeter.tel, dig loc delphinusdns.org ** PS: my phone is down for the moment until I remember the AVM router password.
Strange behaviour of X11 and firefox
Long ago I wanted to run firefox on OpenBSD on an OpenBSD xterm displayed on an X server running on FreeBSD. I expected, of course, a firefox running on OpenBSD displayed on my FreeBSD X server. What else could I have expected? To my surprise, it run the firefox installed on FreeBSD. I found it annoying, it is not what I wanted, not what I expected, at least not without warning and asking me before. I would have wanted that, I would have issued the command on my local machine. The whole time I asked me, how firefox did that, why X11 allowed it. Now, I think here is the answer: https://askubuntu.com/questions/3515/how-do-i-launch-a-remote-firefox-window-via-ssh Is there a way to disable that behaviour as default? Is this "feature" not a misuse of the X shared memory extension? Rod.
Re: "native TeX Live" installation on OpenBSD
Am Sa., 22. Juni 2024 um 17:22 Uhr schrieb Robert Alessi : ... > I would like to share that since the release of TeX Live 2024, anyone Thanks! > The page given above provides an easy way to build one's own custom > binaries to be used for the installation of TeX Live 2024 over the > internet. Do you mean to compile tex commands? What about this: https://github.com/TeX-Live/texlive-source/blob/trunk/README.2building > I hope that anyone interested in the idea of constantly updating TeX > Live over the year with the "tlmgr" standard utility will enjoy this > little project. I am really not interested of constantly updating TeX Live over the year, not at all. I have my texmf directory than rarely change, after updating OpenBSD I recompile the commands. But am I "interested in the idea of constantly updating"? Perhaps! Only out of curiosity. Please, tell me, do you constantly update TeX? How did you came to idea? I really wonder how TeX Life inflated TeX. Rod.
Re: "native TeX Live" installation on OpenBSD
> I am really not interested of constantly updating TeX Live over the year, > not at all. I have my texmf directory than rarely change, after updating > OpenBSD I recompile the commands. I don't particularly care about updating it constantly either, but I do want to isolate it from the rest of my system so it doesn't clutter it up with a load of random stuff. For that I use a personal project called pkg_bundle [1]. It creates standalone and "relocatable" package installs of many large bits of OpenBSD software. $ pkg_bundle texlive_texmf-full # cp -R texlive_texmf-full /opt/texlive $ /opt/texlive/bin/pdflatex path/to/file.tex There is a lot to LaTeX so likely there is a lot missing. I tend to only need to expose pdflatex for much of my uses. [1] https://codeberg.org/kpedersen/pkg_bundle
M-Audio Fast Track Ultra 8R
This is current/amd64 on a PC (full dmesg below). I got my hands on an M-Audio Fast Track Ultra 8R, an USB audio interface; eight tracks, 24/96, nice. It doesn't seem to be supported though: it attaches as an ugen, but no uaudio. umidi0 at uhub4 port 2 configuration 1 interface 3 "M-Audio Fast Track Ultra 8R" rev 2.00/1.51 addr 3 umidi0: (genuine USB-MIDI) umidi0: out=1, in=1 midi0 at umidi0: ugen0 at uhub4 port 2 configuration 1 "M-Audio Fast Track Ultra 8R" rev 2.00/1.51 addr 3 This happens in any USB slot. What can I do to debug this? Is anyone using this on OpenBSD? It is an USB-compliant audio device, macOS and Windows use it just fine. Jan OpenBSD 7.5-current (GENERIC.MP) #152: Wed Jun 26 20:42:02 MDT 2024 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8285454336 (7901MB) avail mem = 8011190272 (7640MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf0100 (36 entries) bios0: vendor Award Software International, Inc. version "F3" date 03/31/2011 bios0: Gigabyte Technology Co., Ltd. H67MA-USB3-B3 acpi0 at bios0: ACPI 1.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP HPET MCFG ASPT SSPT EUDS MATS TAMG APIC SSDT acpi0: wakeup devices PCI0(S5) PEX0(S5) PEX1(S5) PEX2(S5) PEX3(S5) PEX4(S5) PEX5(S5) PEX6(S5) PEX7(S5) HUB0(S5) UAR1(S3) USBE(S3) USE2(S3) AZAL(S5) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimcfg0 at acpi0 acpimcfg0: addr 0xf400, bus 0-63 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3492.10 MHz, 06-2a-07, patch 002f cpu0: cpuid 1 edx=bfebfbff ecx=17bae3ff cpu0: cpuid 6 eax=77 ecx=9 cpu0: cpuid 7.0 edx=9c000400 cpu0: cpuid a vers=3, gp=4, gpwidth=48, ff=3, ffwidth=48 cpu0: cpuid d.1 eax=1 cpu0: cpuid 8001 edx=28100800 ecx=1 cpu0: cpuid 8007 edx=100 cpu0: MELTDOWN cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 8-way L2 cache, 8MB 64b/line 16-way L3 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3492.14 MHz, 06-2a-07, patch 002f cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3492.21 MHz, 06-2a-07, patch 002f cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3492.25 MHz, 06-2a-07, patch 002f cpu3: smt 0, core 3, package 0 cpu4 at mainbus0: apid 1 (application processor) cpu4: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3492.41 MHz, 06-2a-07, patch 002f cpu4: smt 1, core 0, package 0 cpu5 at mainbus0: apid 3 (application processor) cpu5: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3492.27 MHz, 06-2a-07, patch 002f cpu5: smt 1, core 1, package 0 cpu6 at mainbus0: apid 5 (application processor) cpu6: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3492.29 MHz, 06-2a-07, patch 002f cpu6: smt 1, core 2, package 0 cpu7 at mainbus0: apid 7 (application processor) cpu7: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3492.37 MHz, 06-2a-07, patch 002f cpu7: smt 1, core 3, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins, remapped acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (PEG0) acpiprt2 at acpi0: bus -1 (PEG1) acpiprt3 at acpi0: bus 2 (PEX0) acpiprt4 at acpi0: bus -1 (PEX1) acpiprt5 at acpi0: bus -1 (PEX2) acpiprt6 at acpi0: bus -1 (PEX3) acpiprt7 at acpi0: bus 3 (PEX4) acpiprt8 at acpi0: bus 4 (PEX5) acpiprt9 at acpi0: bus 5 (PEX6) acpiprt10 at acpi0: bus 6 (PEX7) acpibtn0 at acpi0: PWRB acpipci0 at acpi0 PCI0 acpicmos0 at acpi0 com0 at acpi0 UAR1 addr 0x3f8/0x8 irq 4: ns16550a, 16 byte fifo acpicpu0 at acpi0: C3(350@96 mwait.1@0x20), C2(500@64 mwait.1@0x10), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: C3(350@96 mwait.1@0x20), C2(500@64 mwait.1@0x10), C1(1000@1 mwait.1), PSS acpicpu2 at acpi0: C3(350@96 mwait.1@0x20), C2(500@64 mwait.1@0x10), C1(1000@1 mwait.1), PSS acpicpu3 at acpi0: C3(350@96 mwait.1@0x20), C2(500@64 mwait.1@0x10), C1(1000@1 mwait.1), PSS acpicpu4 at acpi0: C3(350@96 mwait.1@0x20), C2(500@64 mwait.1@0x10), C1(1000@1 mwait.1), PSS acpicpu5 at acpi0: C3(350@96 mwait.1@0x20), C2(500@64 mwait.1@0x10), C1(1000@1 mwait.1), PSS acpicpu6 at acpi0: C3(350@96 mwait.1@0x20), C2(500@64 mwait.1@0x10), C1(1000@1 mwait.1), PSS acpicpu7 at acpi0: C3(350@96 mwait.1@0x20), C2(500@64 mwait.1@0x10), C1(1000@1 mwait.1), PSS cpu0: using VERW MDS workaround (except on vmm entry) cpu0: Enhanced SpeedStep 3492 MHz: speeds: 3701, 3700, 3600, 3500, 3400, 3300, 3200, 3100, 3000, 2900, 2800, 2700, 2600, 2500, 2400, 2300, 2200, 2100, 1600 MHz
Re: M-Audio Fast Track Ultra 8R
On Sun, Jun 30, 2024 at 08:26:06AM +0200, Jan Stary wrote: > What can I do to debug this? usbdevs -vv would be interesting. > uhub4: device problem, disabling port 2 Is this error reported each time you connect the device, or was it just co-incidence that it happened this time? If it does appear each time, does it make any difference booting with it connected verses hotplugging?
