possible hardware incompatibility with HP 2000 2d27DX
Most of the hardware functionality works under OpenBSD, but there are some missing. First, I can't control brightness input, even through wsconsctl (as there are no values to set brightness input). Second, I can't shutdown the computer properly. Issuing halt -p halts the system but doesn't turn off the computer as I had experienced with other hardware under OpenBSD. OpenBSD 6.6-current (GENERIC.MP) #84: Fri Mar 27 23:50:29 MDT 2020 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 3702251520 (3530MB) avail mem = 3577438208 (3411MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xbf9bc000 (44 entries) bios0: vendor Insyde version "F.37" date 06/26/2013 bios0: Hewlett-Packard HP 2000 Notebook PC acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP UEFI HPET APIC MCFG ASF! BOOT FPDT MSDM SSDT SSDT VFCT SSDT SSDT SSDT SSDT SSDT BGRT acpi0: wakeup devices GPP0(S5) GPP1(S4) OHC1(S3) OHC2(S3) OHC3(S3) EHC1(S3) EHC2(S3) EHC3(S3) XHC0(S4) ODD8(S3) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpihpet0 at acpi0: 14318180 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD A6-5200 APU with Radeon(TM) HD Graphics, 1996.51 MHz, 16-00-01 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PCTRL3,ITSC,BMI1,XSAVEOPT cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 16-way L2 cache cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD A6-5200 APU with Radeon(TM) HD Graphics, 1996.27 MHz, 16-00-01 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PCTRL3,ITSC,BMI1,XSAVEOPT cpu1: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 16-way L2 cache cpu1: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu1: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: AMD A6-5200 APU with Radeon(TM) HD Graphics, 1996.27 MHz, 16-00-01 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PCTRL3,ITSC,BMI1,XSAVEOPT cpu2: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 16-way L2 cache cpu2: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu2: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: AMD A6-5200 APU with Radeon(TM) HD Graphics, 1996.27 MHz, 16-00-01 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PCTRL3,ITSC,BMI1,XSAVEOPT cpu3: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 16-way L2 cache cpu3: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu3: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu3: smt 0, core 3, package 0 ioapic0 at mainbus0: apid 0 pa 0xfec0, version 21, 24 pins ioapic1 at mainbus0: apid 5 pa 0xfec01000, version 21, 32 pins, remapped acpimcfg0 at acpi0 acpimcfg0: addr 0xf800, bus 0-63 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (GPP0) acpiprt2 at acpi0: bus 5 (GPP1) acpiprt3 at acpi0: bus 6 (GPP2) acpiprt4 at acpi0: bus -1 (GPP3) acpiprt5 at acpi0: bus -1 (GFX_) acpiec0 at acpi0 acpicpu0 at acpi0: C2(0@400 io@0x414), C1(@1 halt!), PSS acpicpu1 at acpi0: C2(0@400 io@0x414), C1(@1 halt!), PSS acpicpu2 at acpi0: C2(0@400 io@0x414), C1(@1 halt!), PSS acpicpu3 at acpi0: C2(0@400 io@0x414), C1(@1 halt!), PSS acpipwrres0 at acpi0: FN00, resource for FAN0 acpitz0 at acpi0: critical temperature is 120 degC acpibtn0 at acpi0: PWRB acpipci0 at acpi0 PCI0: 0x00
Re: opensmtpd updates not in OPENBSD_6_6 branch?
> On Apr 8, 2020, at 16:48, Daniel Jakots wrote: > >> I updated usr.sbin/smtpd to HEAD, and now get 6.6.4. > > You're lagging, it's been bumped to 6.7.0 13 hours ago :) > https://github.com/openbsd/src/commit/3b6172845ca039729e3ac02040d787f83f9c7250 Heh. Well, I wanted 6.6.4, so I'm glad I got to it. :-) > I think your approach is wrong. You're assuming the version number > matters but it doesn't. What matters is that you have the fixes. > > Each errata contains the diff, check the code you have to see if it has > the patches. Okay. Well, I didn't check the errata specifically, just the note that it was fixed in 6.6.4. I see now that the 6.6.0 in the tree has had changes (since finding out OPENBSD_6_6_BASE existed, so I can diff against it) > I don't understand your "it looks like". The whole code is free. Look at > the commits instead of guessing. Because I don't know how to look at the commits. I know a lot of how to do that in various trees, but not with OpenBSD. As it is, after getting this email I tried to figure out how to do it. But the github mirror doesn't have any branch or tag info to use, and using http://cvsweb.openbsd.org/ I didn't manage to figure out how to view commits in a branch before noticing the existence of the OPENBSD_6_6_BASE tag and choosing to do it on the command-line. Apologies if I came off as uninformed. I am certainly less informed than I'd like to be, and I appreciate your help in figuring out where I was misunderstanding things... - Chris
Re: secure MTA (was: news from ...)
Claus Assmann writes: > On Wed, Apr 08, 2020, Kevin Chadwick wrote: > >> OpenSMTPD does not listen to the internet, by default and even if you do set >> it > > From: Qualys Security Advisory > To: oss-secur...@lists.openwall.com > Message-ID: <20200224184538.GF17396@localhost.localdomain> > > - Client-side exploitation: This vulnerability is remotely exploitable > in OpenSMTPD's (and hence OpenBSD's) default configuration. Although > ^^^ My (default) smtpd.conf says: listen on lo0 So how might that be remotely exploitable? Allan
Re: news from my hacked box
> yes exactly, I know who is the attacker and he has really great of resources > and power. > Most probably he is responsible of the death of a guy in my country. > Many people have preconceived ideas about security and about the attackers. > Many people think that an hacker is pushed by money or some kind of interest > and > attack just people that he doesn't know. If the attacker fail with a target > he just > change target. Then a victim that describe a situation outside of this schema > most > probably will be classified as a paranoid or a troll. Do you have reason to believe, that this evil person has control over your hardware deliveries? Do you have some procurement process in place, which guarantees, that this person can not intercept and xompromise such a shipment? To which extent would you trust authorities to protect you? Once this is done: what is your attack surface? What are the applications facing the big bad internet? Do you have to run public facing services? Is there a way to restrict the level of "public"? DO you have to run applications which connect to random servers on the internet? Have you thought about running these in a virtual machine with snap shoting enabled, which allows you to return to a known safe state?
Re: Ports: how to install dependencies from binaries?
I wrote: > On 2020-04-08, Stuart Longland wrote: > > > Situation is this: I'm wanting to add OPUS support to Asterisk as I have > > an ATA that supports this CODEC, it'd nice to be able to transcode this > > to other formats. I have a work-in-progress patch to the 'asterisk' > > port for doing this (modelled on what's being done for 'asterisk-speex') > > that I'll share once I've done some testing on both versions. > > This is small/common enough I'd prefer not to add a multipackage. I'm part > way through some other flavour related changes to asterisk so I'd prefer > not to merge in a Makefile diff at the moment but I'll add opus support > to what I have. Do you just need --with-opus or also --with-opusfile? Ohcodec support not just res_format_attr_opus.so, so that's using code which isn't part of Asterisk repo. In that case I would not like to have it in the main port but perhaps it could be built as a standalone thing like is done for asterisk-g729.
Re: opensmtpd updates not in OPENBSD_6_6 branch?
> On Apr 7, 2020, at 21:52, Daniel Jakots wrote: > >> Hello all. I am running a OpenBSD 6.6 that I installed late last >> year. I was recently trying to make sure I'd updated my smtpd to >> 6.6.4, based on earlier security announcement. >> But, I find that >> OPENBSD_6_6 only has smtpd 6.6.0 in it. I was of the impression >> that was the stable branch, and as such it should get updates, >> especially including security updates. >> > > The syspatch creation process includes committing to the > (old)stable branch. AFAIK, what happened here is that the fixes were > backported but the version wasn't bumped. > But if you want to be sure, check the code you're going to compile. I updated usr.sbin/smtpd to HEAD, and now get 6.6.4. If I diff that dir against the same in OPENBSD_6_6, there are a few thousand lines of unified diffs, clearly showing many changes. I don't know for sure that it means what's in OPENBSD_6_6 is the same smtpd 6.6.0 that shipped with OpenBSD 6.6.0, but it's clearly not the smtpd 6.6.4 that's in HEAD. I'm not sure how the syspatch creation process is involved, but I saw the note from Gilles a month and a half ago[1] suggesting using syspatch to update the system. It looks like that didn't update the stable branch. - Chris [1] https://www.mail-archive.com/misc@opensmtpd.org/msg04888.html
Re: opensmtpd updates not in OPENBSD_6_6 branch?
> On Apr 7, 2020, at 21:52, Daniel Jakots wrote: > >> Hello all. I am running a OpenBSD 6.6 that I installed late last >> year. I was recently trying to make sure I'd updated my smtpd to >> 6.6.4, based on earlier security announcement. >> But, I find that >> OPENBSD_6_6 only has smtpd 6.6.0 in it. I was of the impression >> that was the stable branch, and as such it should get updates, >> especially including security updates. >> > > The syspatch creation process includes committing to the > (old)stable branch. AFAIK, what happened here is that the fixes were > backported but the version wasn't bumped. > But if you want to be sure, check the code you're going to compile. I updated usr.sbin/smtpd to HEAD, and now get 6.6.4. If I diff that dir against the same in OPENBSD_6_6, there are a few thousand lines of unified diffs, clearly showing many changes. I don't know for sure that it means what's in OPENBSD_6_6 is the same smtpd 6.6.0 that shipped with OpenBSD 6.6.0, but it's clearly not the smtpd 6.6.4 that's in HEAD. I'm not sure how the syspatch creation process is involved, but I saw the note from Gilles a month and a half ago[1] suggesting using syspatch to update the system. It looks like that didn't update the stable branch. - Chris [1] https://www.mail-archive.com/misc@opensmtpd.org/msg04888.html
Re: news from my hacked box
> "Cord" claims, that people with great resources are out there to get his boxes > hacked. Obviously I can not verify his claim. > yes exactly, I know who is the attacker and he has really great of resources and power. Most probably he is responsible of the death of a guy in my country. Many people have preconceived ideas about security and about the attackers. Many people think that an hacker is pushed by money or some kind of interest and attack just people that he doesn't know. If the attacker fail with a target he just change target. Then a victim that describe a situation outside of this schema most probably will be classified as a paranoid or a troll. But the truth is pretty different, an attacker could be anyone that has enough resources and can be pushed by many reasons, hate, jealousy or other. The attacker could be someone that doesn't know anything about security but he has enough money to pay someone. The complexity of the attack depends of how much money he has and of the target.
Re: opensmtpd updates not in OPENBSD_6_6 branch?
On Wed, 08 Apr 2020 20:29:27 + (UTC), Chris Ross wrote: > I updated usr.sbin/smtpd to HEAD, and now get 6.6.4. You're lagging, it's been bumped to 6.7.0 13 hours ago :) https://github.com/openbsd/src/commit/3b6172845ca039729e3ac02040d787f83f9c7250 > If I diff that > dir against the same in OPENBSD_6_6, there are a few thousand lines of > unified diffs, clearly showing many changes. I don't know for sure > that it means what's in OPENBSD_6_6 is the same smtpd 6.6.0 that > shipped with OpenBSD 6.6.0, but it's clearly not the smtpd 6.6.4 > that's in HEAD. I think your approach is wrong. You're assuming the version number matters but it doesn't. What matters is that you have the fixes. Each errata contains the diff, check the code you have to see if it has the patches. > I'm not sure how the syspatch creation process is involved, but I saw > the note from Gilles a month and a half ago[1] suggesting using > syspatch to update the system. It looks like that didn't update the > stable branch. I don't understand your "it looks like". The whole code is free. Look at the commits instead of guessing. Cheers, Daniel
Re: macpcc sysupgrade missing files
On Tue, Apr 07, 2020 at 04:28:35PM -0600, Theo de Raadt wrote: > There is a problem with some of the mirrors. It is being looked into. thanks! i tried again 24H later using another server near me. sysupgrade got the files. drwxr-xr-x 2 root wheel512 Apr 9 04:56 ./ drwxr-xr-x 5 root wheel512 Apr 1 06:36 ../ -rw-r--r-- 1 root wheel 48017 Apr 8 05:02 INSTALL.macppc -rw-r--r-- 1 root wheel 1820 Apr 9 04:55 SHA256 -rw-r--r-- 1 root wheel 160818907 Apr 8 05:02 base67.tgz -rw-r--r-- 1 root wheel 10387990 Apr 8 05:03 bsd -rw-r--r-- 1 root wheel 10479893 Apr 8 05:03 bsd.mp -rw-r--r-- 1 root wheel8285332 Apr 8 05:03 bsd.rd -rw-r--r-- 1 root wheel 6917 Apr 8 05:03 bsd.tbxi -rw-r--r-- 1 root wheel 72141076 Apr 8 05:03 comp67.tgz -rw-r--r-- 1 root wheel2790961 Apr 8 05:03 game67.tgz -rw-r--r-- 1 root wheel 0 Apr 9 04:56 keep -rw-r--r-- 1 root wheel7634013 Apr 8 05:03 man67.tgz -rw-r--r-- 1 root wheel 19256513 Apr 9 04:55 xbase66.tgz -rw-r--r-- 1 root wheel 19319974 Apr 9 04:55 xbase67.tgz -rw-r--r-- 1 root wheel 40293235 Apr 9 04:55 xfont66.tgz -rw-r--r-- 1 root wheel 40293238 Apr 9 04:56 xfont67.tgz -rw-r--r-- 1 root wheel 12732887 Apr 9 04:56 xserv66.tgz -rw-r--r-- 1 root wheel 12755370 Apr 9 04:56 xserv67.tgz -rw-r--r-- 1 root wheel4608898 Apr 9 04:56 xshare66.tgz -rw-r--r-- 1 root wheel4608911 Apr 9 04:56 xshare67.tgz and 6.7-beta installed after a reboot kern.version=OpenBSD 6.7-beta (GENERIC) #693: Tue Apr 7 00:39:20 MDT 2020 dera...@macppc.openbsd.org:/usr/src/sys/arch/macppc/compile/GENERIC rgc > > rgc wrote: > > > misc@ > > > > was trying to sysupgrade to latest snapshot but got this
Browser tabs crashing if running via X forwarding.
For a couple of weeks now, FireFox (snapshot) has returned a "Gah. Your tab just crashed." error when running it via Putty .73 from Windows 10 using mingw as the X server. Iridium works. grep firefox /var/log/messages (from today): Apr 8 13:11:30 pav /bsd: firefox[70423]: pledge "dns", syscall 97 Apr 8 13:11:32 pav /bsd: firefox[68622]: pledge "dns", syscall 97 Apr 8 13:11:35 pav /bsd: firefox[75512]: pledge "dns", syscall 97 Apr 8 13:12:12 pav /bsd: firefox[22210]: pledge "dns", syscall 97 grep X /var/log/messages from today had no results. No mingw related logs on the Windows side. Output from firefox to the initiating xterm: user@host(~)$firefox & [3] 42685 ed@pav(~)$ ###!!! [Parent][RunMessage] Error: Channel error: cannot send/recv ###!!! [Parent][RunMessage] Error: Channel error: cannot send/recv [Parent 42685, Main Thread] WARNING: FileDescriptorSet destroyed with unconsumed descriptors: file /usr/obj/ports/firefox-74.0.1/firefox-74.0.1/ipc/chromium/src/chrome/common/file_descriptor_set_posix.cc, line 23 dmesg below -- Edward Ahlsen-Girard Ft Walton Beach, FL OpenBSD 6.6-current (GENERIC.MP) #93: Tue Mar 31 12:11:25 MDT 2020 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4176125952 (3982MB) avail mem = 4036952064 (3849MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xec530 (36 entries) bios0: vendor AMI version "80.06" date 04/01/2015 bios0: Hewlett-Packard 550-036 acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT MSDM SSDT SSDT MCFG HPET SSDT SSDT DBGP acpi0: wakeup devices RP01(S4) PXSX(S4) PXSX(S4) PXSX(S4) RP04(S4) PXSX(S4) PXSX(S4) RP06(S4) PXSX(S4) RP07(S4) PXSX(S4) PXSX(S4) GLAN(S4) EHC1(S3) EHC2(S3) XHC_(S3) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i3-4170 CPU @ 3.70GHz, 3691.98 MHz, 06-3c-03 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 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.2.4, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i3-4170 CPU @ 3.70GHz, 3691.47 MHz, 06-3c-03 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 1 (application processor) cpu2: Intel(R) Core(TM) i3-4170 CPU @ 3.70GHz, 3691.46 MHz, 06-3c-03 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 1, core 0, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i3-4170 CPU @ 3.70GHz, 3691.46 MHz, 06-3c-03 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xf800, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (RP01) acpiprt2 at acpi0: bus 2 (RP04) acpiprt3 at acpi0: bus 3 (RP06) acpiprt4 at acpi0: bus 4 (RP07) acpiprt5 at acpi0: bus -1 (PEG0) acpiec0 at acpi0: not present acpicpu0 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: C2(200@148 mwait.1@0x33
Re: news from my hacked box
> security, like OpenBSD works on. Anyone that says anything can be hacked > without > qualification, loses any respect from me, atleast for that moment. Even > browsers "qualification" is very relative word... there are perfect unknown around internet that are high qualified guys. > > To the OP. I apologise if you are not but to me I thought you are/were a > Troll. > If not then I would consider what you posted from the point of view of a > Vulcan. Someone should consider the idea of create a pattern to recognize a troll. And I don't understand you say that my post looks from Vulcan.. also what have done the NSA looks come from Vulcan but certainly it's true. > Did you even consider pxeboot as a vector, if installing from a cafe? HW bios > defaults are often atrocious, unlike OpenBSD defaults! I'm very skeptic about pxe because is disabled on my bios and also the attacker couldn't predict the cafe where I'd go. I chosen the cafe randomly in a big city. > p.s. A web browser that is rarely exploitable is perfectly possible. It would > require some breaking re-design and likely removal if not severe limitations > on > js, for a start though. I'm guessing wasm will not go the right way to fix js. > Perhaps infosec could chime in on improving was but then they would be hurting > their own income streams!! Annoying! Now I'm running an iso from a usb stick and it seems ok but the most thing I miss on openbsd is tool or documentation for forensics analysis. For example now I could mount the disk and make some checking on the kernel, if there are something that it should not stay there, or "alien" (from Vulcan) kernel module installed. I think also would be very useful some driver to dump the ram and analyze it from tools like volatily. It seems that something is moving for freebsd: https://github.com/volatilityfoundation/volatility/blob/freebsd_support/FreeBSD-Support-README.md I think this depends of the idea that openbsd is absolutely secure and it's like a peripheral firewall that defend only the perimeter of a net. Then because openbsd is unbeatable then there aren't any forensic instruments. My idea is that secure means also check the integrity of what is installed.
Re: [/ is full] How to delete junk in /dev ?
On Sun, Apr 05, 2020 at 10:19:30AM +0200, Olivier wrote:
>
> Please, how to identify junk to remove in /dev below :
> ...
> +---> doas find -x / -size +1 -exec du -h {} \;
> 17.9M /bsd
> 9.8M /bsd.rd
> 848K /dev/sdXc
> 884M /dev/sd3
I know you found it already, but this used to happen so often that I
learned to use "ls -l /dev | grep -v ," as a standard check whenever
someone complained about a lack of free space in the root fs.
.robb
Re: secure MTA
Claus Assmann wrote: > > Qualsys chose to call that remote, at a stretch. Either way, it does not > > change > > It seems to be similar to "if you visit a compromised website"... Which is not remote, either. > Anyway, it doesn't seem to be productive to argue terminology etc, > hence: sorry for the interruption and I stop now. Often said by those who are wrong.
Re: secure MTA
On Wed, Apr 08, 2020, Kevin Chadwick wrote: > You missed some out. I assume on purpose. Wrong "assumption"; I did it to keep it short -- I included the info how someone could find the details. > So it does require internal users to make an action and a MITM or outbound > connection to an attacker controlled server and not an incoming connection... Yes, it requires you to send mail according to the exploit that was posted. I did not try it myself and I did not see a followup stating "this does not work". So if that example does not work, maybe someone can clarify? > Qualsys chose to call that remote, at a stretch. Either way, it does not > change It seems to be similar to "if you visit a compromised website"... Anyway, it doesn't seem to be productive to argue terminology etc, hence: sorry for the interruption and I stop now. - Address is valid for this mailing list only, please do not reply to it direcly, but to the list.
Re: secure MTA
On 2020-04-08 18:39, Claus Assmann wrote: > - Client-side exploitation: This vulnerability is remotely exploitable > in OpenSMTPD's (and hence OpenBSD's) default configuration. Although You missed some out. I assume on purpose. Client-side exploitation: This vulnerability is remotely exploitable in OpenSMTPD's (and hence OpenBSD's) default configuration. Although OpenSMTPD listens on localhost only, by default, it does accept mail from local users and delivers it to remote servers. If such a remote server is controlled by an attacker (either because it is malicious or compromised, or because of a man-in-the-middle, DNS, or BGP attack -- SMTP is not TLS-encrypted by default), then the attacker can execute arbitrary shell commands on the vulnerable OpenSMTPD installation. So it does require internal users to make an action and a MITM or outbound connection to an attacker controlled server and not an incoming connection... Qualsys chose to call that remote, at a stretch. Either way, it does not change the point around "everything is hackable" being false. I never brought up smtpd and never said smtpd was unhackable!
Re: secure MTA (was: news from ...)
On Wed, Apr 08, 2020, Kevin Chadwick wrote: > OpenSMTPD does not listen to the internet, by default and even if you do set > it From: Qualys Security Advisory To: oss-secur...@lists.openwall.com Message-ID: <20200224184538.GF17396@localhost.localdomain> - Client-side exploitation: This vulnerability is remotely exploitable in OpenSMTPD's (and hence OpenBSD's) default configuration. Although ^^^ > Is it hard to write a secure mail server, sure. Look at exims bugs. [Is that like saying: "Is it hard to write a secure OS, sure. Look at Linux bugs."? ] How about qmail (or postfix)? (and some other barely known MTA) -- Address is valid for this mailing list only, please do not reply to it direcly, but to the list.
Re: news from my hacked box
On 2020-04-08 18:02, Rudolf Leitgeb wrote: > A public facing server with ftp, http, smtp and sshd would have had to be > patched > in regular intervals to remain reasonably secure. False, even though you have lowered the bar from "anything/everything is hackable". httpd and libressl have done quite well despite talking over http to anyone and dealing with crappy interfaces like ASN.1 for TLS. You missed the point. If your interface requires authentication first, like ssh then that is good, it has a good record. If your interface requires auth in a simple format and is a very simple interface after that fact. Then you will find examples of devices and services that have never been hacked, even without the layers of defence of sshd, though you are free to have some of them! ergo the mantra of anything is hackable is bullshit, largely spread by pen testers and fuzzers. There isn't much to fuzz when auth of a simple key is required up front. Most hacks occur by inside users not remote and that is a whole other matter but that does not mean that anything is hackable. "everything is hackable" is FUD
Re: OpenBSD/sparc64 6.7-beta not working on silver Blade 2500
Am Mi., 8. Apr. 2020 um 08:37 Uhr schrieb Otto Moerbeek : > > On Wed, Apr 08, 2020 at 01:11:29AM +0200, Sigi Rudzio wrote: > > > Hello misc@, > > > > while testing the FFS2 patches by otto@ I noticed that I was unable > > to install -current on my silver Blade 2500. > > > > tar fails while unpacking the sets, although the files are ok, if I rename > > base67.tgz to base66.tgz to fool the 6.6 installer I can install 6.7-beta, > > although it fails/panics with a lot of "Illegal instruction" errors on the > > first boot. > > > > otto@ already told me that this might be fallout from the recent clang > > changes. > > Well, I sais it *could be*, but you did not show my the actual errors > in that email. The errorsbelow indicate a harware issue, i.e. bad > disk. > > -Otto Sorry, I should have been clearer. I tried another disk from my working V240 and got the same errors. Installing on an IDE hard disk works and the system is working fine, even writing large files to the SCSI disk is fine, but I can make it panic with tar. So I guess this is some kind of SCSI bus hardware issue that 6.6 doesn't trigger and some change between 6.6 and 6.7-beta does trigger it. Sorry for the noise and thanks for the help! Regards S. Rudzio > > > > > 6.6 works fine. > > > > The failures are a bit random, it doesn't panic every time, sometimes > > while installing 6.7-beta tar fails and I get to try again a few times > > before > > I give up/it panics. > > > > I hope this information helps. > > > > Regards, > > > > S. Rudzio > > > > output from > > -6.7-beta bsd.rd failing > > -6.6 bsd.rd > > -6.6 bsd.mp > > -6.7-beta bsd.mp failing/panicing (installed with 6.6 bsd.rd) > > following: > > > > latest bsd.rd (the previous two snapshots also failed, but I didn't save any > > logs): > > Booting /pci@1c,60/network@3/bsd.rd > > 4671584@0x100+6048@0x1474860+3248464@0x1c0+945840@0x1f19150 > > symbols @ 0xfec68440 175+356136+219433 start=0x100 > > console is /pci@1e,60/isa@7/serial@0,3f8 > > Copyright (c) 1982, 1986, 1989, 1991, 1993 > > The Regents of the University of California. All rights > > reserved. > > Copyright (c) 1995-2020 OpenBSD. All rights reserved. > > https://www.OpenBSD.org > > > > OpenBSD 6.7-beta (RAMDISK) #259: Mon Apr 6 19:13:12 MDT 2020 > > dera...@sparc64.openbsd.org:/usr/src/sys/arch/sparc64/compile/RAMDISK > > real mem = 2147483648 (2048MB) > > avail mem = 2098044928 (2000MB) > > mainbus0 at root: Sun Blade 2500 (Silver) > > "SUNW,UltraSPARC-IIIi" at mainbus0 not configured > > cpu0 at mainbus0: SUNW,UltraSPARC-IIIi (rev 3.4) @ 1600 MHz > > cpu0: physical 32K instruction (32 b/l), 64K data (32 b/l), 1024K > > external (64 b/l) > > "memory-controller" at mainbus0 not configured > > "memory-controller" at mainbus0 not configured > > schizo0 at mainbus0: "Tomatillo", version 4, ign 700, bus A 0 to 0 > > schizo0: dvma map c000-dfff > > pci0 at schizo0 > > bge0 at pci0 dev 3 function 0 "Broadcom BCM5703" rev 0x00, > > BCM5702/5703 A2 (0x1002)bge0: nvram lock timed out > > : ivec 0x71c, address 00:03:ba:f2:ee:53 > > brgphy0 at bge0 phy 1: BCM5703 10/100/1000baseT PHY, rev. 2 > > "ppm" at mainbus0 not configured > > schizo1 at mainbus0: "Tomatillo", version 4, ign 740, bus B 0 to 0 > > schizo1: dvma map c000-dfff > > pci1 at schizo1 > > mpi0 at pci1 dev 4 function 0 "Symbios Logic 53c1030" rev 0x07: ivec > > 0x769 > > mpi0: 0, firmware 1.3.11.1 > > scsibus0 at mpi0: 16 targets, initiator 7 > > sd0 at scsibus0 targ 0 lun 0: > > serial.SEAGATE_ST314670LSUN146G4442RJNV_3KS2RJNV > > sd0: 140009MB, 512 bytes/sector, 286739329 sectors > > mpi0: target 0 Sync at 160MHz width 16bit offset 63 QAS 1 DT 1 IU 1 > > mpi1 at pci1 dev 4 function 1 "Symbios Logic 53c1030" rev 0x07: ivec > > 0x768 > > mpi1: 0, firmware 1.3.11.1 > > scsibus1 at mpi1: 16 targets, initiator 7 > > schizo2 at mainbus0: "Tomatillo", version 4, ign 780, bus A 0 to 1 > > schizo2: dvma map c000-dfff > > pci2 at schizo2 > > ebus0 at pci2 dev 7 function 0 "Acer Labs M1533 ISA" rev 0x00 > > "flashprom" at ebus0 addr 0-f not configured > > rtc0 at ebus0 addr 70-71: m5823 > > "i2c" at ebus0 addr 320-321 ivec 0x2e not configured > > "power" at ebus0 addr 800-82f ivec 0x20 not configured > > com0 at ebus0 addr 3f8-3ff ivec 0x2c: ns16550a, 16 byte fifo > > com0: console > > com1 at ebus0 addr 2e8-2ef ivec 0x2c: ns16550a, 16 byte fifo > > "dma" at ebus0 addr 0- not configured > > "Acer Labs M7101 Power" rev 0x00 at pci2 dev 6 function 0 not > > configured > > "Acer Labs M5451 Audio" rev 0x02 at pci2 dev 8 function 0 not > > configured > > ohci0 at pci2 dev 10 function 0 "Acer Labs M5237 USB" rev 0x03: ivec > > 0x7a7, version 1.0, legacy support > > ohci1 at pci2 dev 11 function 0 "Acer Labs M5237 USB" rev 0x03: ivec > > 0x7a6, version 1.0, legacy support > > pciide0 at pci2 dev 13 function 0 "Acer Labs M5229 UDMA IDE" rev 0xc4: > > DMA, channel 0 configured to native-PCI, channel 1 configured t
Re: news from my hacked box
> OpenSMTPD does not listen to the internet, by default and even if you do set > it > to, it only affected certain configurations. A server, which does not listen to the outside is pretty useless, don't you think? I did not bring up opensmtp, because it is particularly bad, quite to the contrary: even in very hardened systems bugs happen. You can patch these bugs and have a reasonable secure system, but it's an ongoing effort, not something you do just once. > How the heck sshd has such as good security record, considering all that it > does, interface wise, is rather astounding. I guess a remotely critical bug > may > be found there one day, but it does not affect my point! sshd has a good security record on openbsd, but even with sshd there were problems on other platforms, not caused by the core sshd or the openbsd team, but nonetheless a real issue. Closely related to openssh was openssl, which had a gaping hole that became known just a few years ago. I was not so much shocked about the fact, that there was a security hole in openssl, but how really stupid and unnecessary this whole issue was, what a stupid feature actually caused this bug to be deployed on so many platforms. Again, this is nothing specific to OpenBSD, but let's not delude outselves, that one can rollout some server and leave it as it is for years to come. > If your project, like most could; has made sane design choices for simple > interfaces then it certainly can be made very secure, remotely unhackable is > easier than you think for a modest project. A public facing server with ftp, http, smtp and sshd would have had to be patched in regular intervals to remain reasonably secure. Add a content management service to this configuration, and these "regular intervals" turn into very frequent occurrances. This is valid for low profile stuff, though. If you are something high profile, like a bank, it's a constant and ongoing effort to deal with hackers of all flavors. Cheers, Rudi
Re: Ports: how to install dependencies from binaries?
Daniel Jakots writes:
> On Wed, 8 Apr 2020 13:12:54 +1000, Stuart Longland
> wrote:
>
>> Silly question… how do you install the dependencies of a port from
>> binaries automatically?
>
> https://man.openbsd.org/bsd.port.mk#FETCH_PACKAGES but it doesn't work
> very reliably, sadly.
>
I didn't know about that. What I have done is use the
print-build-depends target. For example, on my machine:
$ cd /usr/ports/telephony/asterisk
$ make print-build-depends
This port requires package(s) "libssh2-1.9.0 bzip2-1.0.8 lynx-2.8.9rel1p0
libusb1-1.0.21p1 npth-1.6 pcre2-10.33 ..." to build.
Then you can copy/paste, or otherwise feed the stuff in between the
quote marks, to pkg_add. I do:
# make print-build-depends | awk -F \" '{print $2}' | xargs pkg_add
Then proceed with building/installing the port of interest.
Allan
Re: Ports: how to install dependencies from binaries?
On 2020-04-08, Stuart Longland wrote: > Hi all, > > Silly question… how do you install the dependencies of a port from > binaries automatically? Apart from the other answers, you can cut down the dep list in many of the larger multi-package ports. FLAVOR="$(make show=FLAVORS:Mno_*)" make [...] (or just take a subset of the no_* flavours). > Situation is this: I'm wanting to add OPUS support to Asterisk as I have > an ATA that supports this CODEC, it'd nice to be able to transcode this > to other formats. I have a work-in-progress patch to the 'asterisk' > port for doing this (modelled on what's being done for 'asterisk-speex') > that I'll share once I've done some testing on both versions. This is small/common enough I'd prefer not to add a multipackage. I'm part way through some other flavour related changes to asterisk so I'd prefer not to merge in a Makefile diff at the moment but I'll add opus support to what I have. Do you just need --with-opus or also --with-opusfile?
Re: news from my hacked box
On 2020-04-08 12:08, Rudolf Leitgeb wrote: >> I believe that is false too. > You're kidding, yes? Did you somehow miss the opensmtp hole? > > https://poolp.org/posts/2020-01-30/opensmtpd-advisory-dissected/ OpenSMTPD does not listen to the internet, by default and even if you do set it to, it only affected certain configurations. Is it hard to write a secure mail server, sure. Look at exims bugs. If your project, like most could; has made sane design choices for simple interfaces then it certainly can be made very secure, remotely unhackable is easier than you think for a modest project. You cannot take the easy road though. How the heck sshd has such as good security record, considering all that it does, interface wise, is rather astounding. I guess a remotely critical bug may be found there one day, but it does not affect my point!
Re: news from my hacked box
> True if you consider physical attacks and for most hardware, otherwise mostly > false. Anything can be hacked is also one of my biggest annoyances as a mantra > from "infosec", that gets more money than it deserves in comparison to real > security, like OpenBSD works on. We know from Snowden, that supply chain attacks are a common thing. If someone can modify the hardware sent to certain people on your list, then operating system security is no longer the most pressing concern. "Cord" claims, that people with great resources are out there to get his boxes hacked. Obviously I can not verify his claim. And I stand by my statement: ordering a computer and setting it up with a secure operating system is insufficient to maintain control over your server. I do concur with your assessment, that 99% of concerned people are way to unimportant to attract any government attacks. These 99% certainly include me. Attacking a server always comes with a risk of discovery, therefore I do not believe, that these agencies conduct mass hacks of random servers. > > Even OpenBSD had a remote root hole just a few weeks ago. > I believe that is false too. You're kidding, yes? Did you somehow miss the opensmtp hole? https://poolp.org/posts/2020-01-30/opensmtpd-advisory-dissected/ Cheers, Rudi
Re: news from my hacked box
On 2020-04-07 18:21, Rudolf Leitgeb wrote: > You have no chance defending your desktop against each and every attacker, no > matter > which operating system you have running. True if you consider physical attacks and for most hardware, otherwise mostly false. Anything can be hacked is also one of my biggest annoyances as a mantra from "infosec", that gets more money than it deserves in comparison to real security, like OpenBSD works on. Anyone that says anything can be hacked without qualification, loses any respect from me, atleast for that moment. Even browsers take some skill/time to hack and a modern browser is anakin to putting the Death Star exhaust port in the hangar of a Mon Calamari Cruiser. Even OpenBSD had a remote root hole just > a few weeks ago. I believe that is false too. To the OP. I apologise if you are not but to me I thought you are/were a Troll. If not then I would consider what you posted from the point of view of a Vulcan. Did you even consider pxeboot as a vector, if installing from a cafe? HW bios defaults are often atrocious, unlike OpenBSD defaults! p.s. A web browser that is rarely exploitable is perfectly possible. It would require some breaking re-design and likely removal if not severe limitations on js, for a start though. I'm guessing wasm will not go the right way to fix js. Perhaps infosec could chime in on improving was but then they would be hurting their own income streams!! Annoying!
