Re: root access after failed fsck

[lists]

Sat, 20 Feb 2016 11:52:32 +0100 arrowscr...@mail.com
> Wow, that's new to me. Thanks.

Yep, the FAQ is pretty new and shiny.  FAQ8 general questions.
FAQ10 system  management.  A must read for half the questions you may
have in general use.  The entire FAQ is the first thing to query before
the mailing list.  If you are unsure about a man page, check the FAQ
and search online.   OpenBSD Resources section on the main page is
listing the items in order for a specific reason.

> Anyway, I still think that this "password rescue" should not be
> allowed by default.

You'll get flak for this, it is not what you think, it is what's right
for the majority of users on the system.  Nobody wants to be bothered
for workaround, and most people manage quite more than the number of
machines you run at home occasionally OpenBSD.

> I know operating systems can do very little to prevent physical
> problems like side-channel attacks, but this is not the case, and
> this does not mean that the OS should not make it harder the attacks
> even if someone have physical access. There's systems, from what I
> remember (HP servers, I think), that allow remote control based on
> firmware. One could use this escape "feature" to get your root,
> without physical access. Same for hosts services.

If you think this has not been talked and repeated yet... read this
message again.

> Also, the page 14.21 from faq say "I forgot my passphrase! Sorry.
> This is real encryption, there's not a back door or magic unlocking
> tool." why exactly the root should be different?

The word encryption makes it not equivalent to single user.  Consistency
should be sought where applicable only, not as a magic wand regular
expression.

> If one lost his passphrase, it's his fault. I thought the philosophy
> was "secure by default", even if this make the "computer difficult to
> manage properly".

You're not making much sense but if you want to continue, don't say
it's somebody shouting at you later.  Read the FAQ again and ponder why
it is so, and not how it should be according to your single use case.

Re: root access after failed fsck

[George Mamalakis]

On 20/02/2016 12:52 μμ, arrowscr...@mail.com wrote:

Wow, that's new to me. Thanks.
Anyway, I still think that this "password rescue" should not be allowed by 
default.
I know operating systems can do very little to prevent physical problems like 
side-channel attacks,
but this is not the case, and this does not mean that the OS should not make it 
harder the attacks even
if someone have physical access. There's systems, from what I remember (HP 
servers, I think), that
allow remote control based on firmware. One could use this escape "feature" to 
get your root,
without physical access. Same for hosts services.
Also, the page 14.21 from faq say "I forgot my passphrase! Sorry. This is real 
encryption, there's
not a back door or magic unlocking tool." why exactly the root should be 
different? If one lost his
passphrase, it's his fault. I thought the philosophy was "secure by default", 
even if this make the
"computer difficult to manage properly".

Moreover, this is also the case with most Linux distro's  you've 
probably used in your life. You may have to enter a password on some 
distro's when in single-user mode, but grub is almost always 
passwordless, which means you can edit it to set /bin/bash as init, 
which basically bypasses all such "restrictions".


Secure by default does not mean that everything is hardened, as this 
wouldn't be that practical either. One could argue that file system 
permissions on binary and library folders could be more strict, or that 
systrace should have been setup and configured by default, but I think 
that this by far exceeds what a "secure OS" would be and enforces 
probable restrictions on sysadmins that they may not want to adhere to. 
I don't think that the goal of a proactively secure OS like OpenBSD is 
to be configured to be hardened by default so as to be used by expert or 
non-expert admins to feel safer, because that would be more misleading 
than helpful, as Stuart suggested. The goal is to have a generically 
safe OS where program crashes don't result in privilege escalation that 
easily and whose code is designed and written with security in mind to 
reduce vulnerabilities. It's the sysadmins' responsibility to further 
"secure" their installations and chose which features they'd further add 
which would probably make OS maintenance more difficult.


Having said that, to my understanding, securing physical access by 
asking the pass phrase in single-user mode in an OS would be more than a 
marketing thing rather than a security feature per-se.


George.

Re: root access after failed fsck

[Stuart Henderson]

On 2016-02-20, arrowscr...@mail.com  wrote:
> Wow, that's new to me. Thanks.
> Anyway, I still think that this "password rescue" should not be allowed by 
> default.

> Also, the page 14.21 from faq say "I forgot my passphrase! Sorry. This is 
> real encryption, there's
> not a back door or magic unlocking tool." why exactly the root should be 
> different? If one lost his
> passphrase, it's his fault. I thought the philosophy was "secure by default", 
> even if this make the
> "computer difficult to manage properly".

Requiring the root password to enter single-user mode would only *reduce*
security, by making people feel safer than they are. It's an easy task to
boot an install kernel (bsd.rd) or another OS or, if you have physical
access to the machine, move the disk to another machine, and access the
disk from there.

If you don't want people to access the files, encrypt them. Anything else
is smoke and mirrors.

Re: root access after failed fsck

[arrowscript]

Wow, that's new to me. Thanks.
Anyway, I still think that this "password rescue" should not be allowed by 
default.
I know operating systems can do very little to prevent physical problems like 
side-channel attacks,
but this is not the case, and this does not mean that the OS should not make it 
harder the attacks even
if someone have physical access. There's systems, from what I remember (HP 
servers, I think), that
allow remote control based on firmware. One could use this escape "feature" to 
get your root,
without physical access. Same for hosts services.
Also, the page 14.21 from faq say "I forgot my passphrase! Sorry. This is real 
encryption, there's
not a back door or magic unlocking tool." why exactly the root should be 
different? If one lost his
passphrase, it's his fault. I thought the philosophy was "secure by default", 
even if this make the
"computer difficult to manage properly".

Re: root access after failed fsck

[Stuart Henderson]

On 2016-02-20, arrowscr...@mail.com  wrote:
> Some minutes ago I had a energy blackout here in my city. I was running 
> OpenBSD. 
> When I booted after energy came back, the system did the usual fsck. 
> But this time something went wrong and he just escaped to root, without 
> asking for any passphrase.
> The system did a question like "point the path to sh", and I just typed 
> "/bin/sh" and he gained access to root.
> I think this is a serious security problem folks. I have softraid_crypto, so 
> no problem for me, but one could (probably) induce this failure to access 
> root when no FDE configured and he have physical access (or remove, who know 
> with all these Intel AMT microcodes).

http://www.openbsd.org/faq/faq8.html#LostPW

Read to the bottom of the question ("wait, that looked too easy").
We should add something about FDE to that question though.

Re: root access after failed fsck

[George Mamalakis]

As in all BSD's I know of, edit /etc/ttys (as root) and change console 
to be insecure (it defaults to "secure"). This way you'll be asked for a 
password when in single user mode.


This is no security issue, it is how single user mode "operates" and 
it's configurable.


George.

PS. Be sure you won't forget your root's password :).
PS2. Physical access to a box (which is usually implied when running in 
single user mode) can almost certainly lead to a compromised machine.


On 20/02/2016 10:59 πμ, arrowscr...@mail.com wrote:

Some minutes ago I had a energy blackout here in my city. I was running OpenBSD.
When I booted after energy came back, the system did the usual fsck.
But this time something went wrong and he just escaped to root, without asking 
for any passphrase.
The system did a question like "point the path to sh", and I just typed 
"/bin/sh" and he gained access to root.
I think this is a serious security problem folks. I have softraid_crypto, so no 
problem for me, but one could (probably) induce this failure to access root 
when no FDE configured and he have physical access (or remove, who know with 
all these Intel AMT microcodes).
The /var/log/ have none logs about it, all I can show is the dmesg (if you need 
more information, just ask):

OpenBSD 5.9-beta (GENERIC.MP) #1864: Mon Jan 25 19:11:29 MST 2016
 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 16481857536 (15718MB)
avail mem = 15978151936 (15237MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe98e0 (94 entries)
bios0: vendor American Megatrends Inc. version "1601" date 11/27/2013
bios0: ASUSTeK COMPUTER INC. P8H61-M LX2 R2.0
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT MCFG SSDT BGRT SSDT SSDT DMAR
acpi0: wakeup devices P0P1(S4) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PEGP(S4) 
PEG0(S4) PEG1(S4) PEG2(S4) PEG3(S4) PXSX(S4) RP04(S4) PXSX(S4) RP03(S4) 
PS2K(S4) PS2M(S4) [...]
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) i5-3470 CPU @ 3.20GHz, 3200.43 MHz
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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT
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 100MHz
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) i5-3470 CPU @ 3.20GHz, 3200.03 MHz
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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Core(TM) i5-3470 CPU @ 3.20GHz, 3200.02 MHz
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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Core(TM) i5-3470 CPU @ 3.20GHz, 3200.02 MHz
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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 0, core 3, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0 addr 0xf800, bus 0-63
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (P0P1)
acpiprt2 at acpi0: bus 2 (RP01)
acpiprt3 at acpi0: bus -1 (RP02)
acpiprt4 at acpi0: bus 1 (PEG0)
acpiprt5 at acpi0: bus -1 (PEG1)
acpiprt6 at acpi0: bus -1 (PEG2)
acpiprt7 at acpi0: bus -1 (PEG3)
acpiprt8 at acpi0: bus 5 (RP04)
acpiprt9 at acpi0: bus 3 (RP03)
acpiprt10 at acpi0: bus 4 (PXSX)
acpiec0 at acpi0: not present
acpicpu0 at acpi0: C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0: C1(1000@1 mwait.1), PSS
acpicpu2 at acpi0: C1(1000@1 mwait.1), PSS
acpicpu3 at acpi0: C1(1000@1 mwait.1), PSS
acpipwrres0 at acpi0: FN00, resource for FAN0
acpipwrres1 at acpi0: FN01, resource for FAN1
acpipwrres2 at 

root access after failed fsck

[arrowscript]

Some minutes ago I had a energy blackout here in my city. I was running 
OpenBSD. 
When I booted after energy came back, the system did the usual fsck. 
But this time something went wrong and he just escaped to root, without asking 
for any passphrase.
The system did a question like "point the path to sh", and I just typed 
"/bin/sh" and he gained access to root.
I think this is a serious security problem folks. I have softraid_crypto, so no 
problem for me, but one could (probably) induce this failure to access root 
when no FDE configured and he have physical access (or remove, who know with 
all these Intel AMT microcodes).
The /var/log/ have none logs about it, all I can show is the dmesg (if you need 
more information, just ask):

OpenBSD 5.9-beta (GENERIC.MP) #1864: Mon Jan 25 19:11:29 MST 2016
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 16481857536 (15718MB)
avail mem = 15978151936 (15237MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe98e0 (94 entries)
bios0: vendor American Megatrends Inc. version "1601" date 11/27/2013
bios0: ASUSTeK COMPUTER INC. P8H61-M LX2 R2.0
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT MCFG SSDT BGRT SSDT SSDT DMAR
acpi0: wakeup devices P0P1(S4) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PEGP(S4) 
PEG0(S4) PEG1(S4) PEG2(S4) PEG3(S4) PXSX(S4) RP04(S4) PXSX(S4) RP03(S4) 
PS2K(S4) PS2M(S4) [...]
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) i5-3470 CPU @ 3.20GHz, 3200.43 MHz
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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT
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 100MHz
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) i5-3470 CPU @ 3.20GHz, 3200.03 MHz
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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Core(TM) i5-3470 CPU @ 3.20GHz, 3200.02 MHz
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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Core(TM) i5-3470 CPU @ 3.20GHz, 3200.02 MHz
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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 0, core 3, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0 addr 0xf800, bus 0-63
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (P0P1)
acpiprt2 at acpi0: bus 2 (RP01)
acpiprt3 at acpi0: bus -1 (RP02)
acpiprt4 at acpi0: bus 1 (PEG0)
acpiprt5 at acpi0: bus -1 (PEG1)
acpiprt6 at acpi0: bus -1 (PEG2)
acpiprt7 at acpi0: bus -1 (PEG3)
acpiprt8 at acpi0: bus 5 (RP04)
acpiprt9 at acpi0: bus 3 (RP03)
acpiprt10 at acpi0: bus 4 (PXSX)
acpiec0 at acpi0: not present
acpicpu0 at acpi0: C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0: C1(1000@1 mwait.1), PSS
acpicpu2 at acpi0: C1(1000@1 mwait.1), PSS
acpicpu3 at acpi0: C1(1000@1 mwait.1), PSS
acpipwrres0 at acpi0: FN00, resource for FAN0
acpipwrres1 at acpi0: FN01, resource for FAN1
acpipwrres2 at acpi0: FN02, resource for FAN2
acpipwrres3 at acpi0: FN03, resource for FAN3
acpipwrres4 at acpi0: FN04, resource for FAN4
acpitz0 at acpi0: critical temperature is 106 degC
acpitz1 at acpi0: critical temperature is 106 degC
acpibat0 at acpi0: BAT0 not present
acpibat1 at acpi0: BAT1 not present
acpibat2 at acpi0: BAT2 not present
acpibtn0 at acpi0: PWRB
acpibtn1 at acpi0: LID0
acpivideo0 at acpi0: GFX0
acpivout0 at acpivideo0: DD02
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Core 3G Host" rev 0x09
ppb0 at pci0