Re: httpd violates pledge with passworded private key

2017-06-07 Thread Ted Unangst 
Jonathan Gray wrote:
> when using a server.key with a passphrase, ie


> ) at /usr/src/lib/libc/stdio/fopen.c:54
> #3  0x022b2d92d26f in open_console (ui=Variable "ui" is not available.
> ) at /usr/src/lib/libcrypto/ui/ui_openssl.c:304

> #6  0x022b2d9dc018 in PEM_def_callback
> ) at /usr/src/lib/libcrypto/pem/pem_lib.c:113

> #10 0x022b6ef43b62 in tls_configure_ssl_keypair

ugh, i think this is a bug in libtls. there should not be sneaky bullshit
console reading functions being called behind the scenes. this is, as
discovered, kind of surprising. and quite the layering violation, separation
of concerns, and all that.

a sane API would look something like this:

tls_configure_keypair() -> return EWANTSPASSWORD -> application decides how to
proceed, possibly asking for password, calls
tls_configure_keypair_this_time_with_password().

monitor doesn't detect a signal after kernel mode switching with newer snapshots

2017-06-07 Thread Eckehard Berns 
>Synopsis:  monitor doesn't detect a signal after kernel mode switching 
>with newer snapshots
>Category:  kernel
>Environment:
System  : OpenBSD 6.1
Details : OpenBSD 6.1-current (GENERIC.MP) #106: Tue Jun  6 
13:54:54 MDT 2017
 
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

Architecture: OpenBSD.amd64
Machine : amd64
>Description:
With the snapshot from the 6th (and the 5th, but not from May 28th)
my monitor reports no signal after the kernel switches modes during
the boot process. Inteldrm also reports "1024x768, 32bpp" instead
of the usual "1920x1080, 32bpp".
The monitor is attached via DVI (although xrandr reports it as HDMI1).
When I attached a second monitor via VGA that one would receive a
signal and show the screen in 1024x768.
The attached dmesg is from when I booted the kernel #106. The
pcidump, acpidump and usbdevs where taken by sendbug when I booted
the kernel I compiled from yesterday's sources.
>How-To-Repeat:
Boot the kernel #106 with my setup. Sorry, but since I saw no
other bug reports my guess is this is a hardware specific problem.
>Fix:
When I first experienced this problem yesterday, I checked out
src/sys and built my own kernel using the standard GERNERIC.MP
with no modifications. That kernel works fine and kernel mode
switching works a before.


dmesg:
OpenBSD 6.1-current (GENERIC.MP) #106: Tue Jun  6 13:54:54 MDT 2017
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8241012736 (7859MB)
avail mem = 7985463296 (7615MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeb8c0 (108 entries)
bios0: vendor American Megatrends Inc. version "0402" date 01/18/2013
bios0: ASUSTeK COMPUTER INC. Z77-A
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT MCFG HPET SSDT BGRT SSDT SSDT
acpi0: wakeup devices PS2K(S4) UAR1(S4) P0P1(S4) PXSX(S4) RP01(S4) PXSX(S4) 
RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PEGP(S4) 
PEG0(S4) PEG1(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-2500K CPU @ 3.30GHz, 3310.25 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,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: TSC frequency 3310247040 Hz
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-2500K CPU @ 3.30GHz, 3309.73 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,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,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-2500K CPU @ 3.30GHz, 3309.73 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,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,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-2500K CPU @ 3.30GHz, 3309.73 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,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,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
acpihpet0 at acpi0: 14318179 Hz
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 (RP03)
acpiprt5 at acpi0: bus -1 (RP04)
acpiprt6 at acpi0: bus 3 (RP05)
acpiprt7 at acpi0: bus 1 (PEG0)
acpiprt8 at acpi0: bus -1 (PEG1)
acpiprt9 at acpi0: bus -1 (PEG2)
acpiprt10 at acpi0: bus -1 (PEG3)
acpiprt11 at acpi0: bus -1 (RP07)
acpiprt12 at acpi0: bus -1 (RP08)
acpiprt13 at acpi0: bus 4 (RP06)
acpiprt14 at acpi0: bus 5 (PXSX)
acpiec0 at

Re: Kernel panic on 6.1: init dies under load

2017-06-07 Thread Dan Cross 
Wonderful, Mike. I just rebuilt kernels and am running some largish jobs
and everything seems to be surviving. Thanks for turning around a fix so
quickly!

On Tue, Jun 6, 2017 at 5:26 PM, Mike Belopuhov  wrote:

> Hi,
>
> I've checked in a slightly amended version of the diff.
>
> Regards,
> Mike
>
> On Sat, Jun 03, 2017 at 19:03 +0200, Mike Belopuhov wrote:
> > Hi Dan,
> >
> > That's good news, thanks for testing!  I've updated the diff
> > slightly.  Unfortunately I couldn't figure out what's causing
> > "boot dump" to crash.  I've exercised coredump, physio and
> > read-ahead codepaths.  I'll commit the diff next week unless
> > there's going to be reports of some breakage.
> >
> > The diff is available from the same location as previously:
> > http://gir.theapt.org/~mike/xbf.diff
> >
> > Thanks for testing!
> >
> > On 27 May 2017 at 03:33, Dan Cross  wrote:
> >
> > > Thanks for this latest patch; it seems to help. At least, I was able to
> > > put a fairly significant amount of load on the machine with out a
> panic.
> > > I'll try and load it up more and see where we get, but so far this is
> > > positive.
> > >
> > > On Wed, May 24, 2017 at 7:37 PM, Mike Belopuhov 
> > > wrote:
> > >
> > >> On Wed, May 24, 2017 at 12:27 -0400, Dan Cross wrote:
> > >> > Thanks for the patch; I just got a few minutes today and I applied
> it,
> > >> > rebuilt and installed the kernel and rebooted. Sadly, I get a
> similar
> > >> > panic. Attached is a screenshot of console output. Note that, 'boot
> > >> sync'
> > >> > from ddb hangs forever.
> > >> >
> > >> > - Dan C.
> > >>
> > >> That's OK. I've discovered more problems related to 64k transfers.
> > >> The reason why we didn't notice anything bad when aborting sleep
> > >> was because sleep has a small memory footprint, but if you dump
> > >> core of a larger (> 64k) program, you'd notice the issue because
> > >> core dump routine like some other places in the kernel assumes
> > >> that 64k transfers always work.
> > >>
> > >> I've attempted to attack this problem from a different angle:
> > >> ensure that xbf(4) can handle 64k transfers.  Solutions to this
> > >> problem are notoriously messy and complicated and so far this
> > >> one is no exception. Today I got to the point where the system
> > >> boots multiuser but couldn't test further. I've noticed however
> > >> that "boot dump" from ddb still crashes so I know it's not 100%
> > >> right just yet, but since I won't get around doing anything
> > >> about this until early next week, I'd appreciate a quick test
> > >> if possible.
> > >>
> > >> I'm not attaching the diff since it's rather large:
> > >>
> > >> http://gir.theapt.org/~mike/xbf.diff
> > >>
> > >> Cheers,
> > >> Mike
> > >>
> > >
> > >
>

Re: httpd violates pledge with passworded private key

2017-06-07 Thread Reyk Floeter 

> Am 06.06.2017 um 22:41 schrieb Florian Obser :
> 
>> On Tue, Jun 06, 2017 at 09:18:25PM +1000, Jonathan Gray wrote:
>> when using a server.key with a passphrase, ie
>> 
>> openssl genrsa -aes256 -out /etc/ssl/private/server.key 2048
>> 
>> server "default" {
>>listen on * port 80
>>listen on * tls port 443
>>directory { auto index }
>> }
>> 
>> types {
>>include "/usr/share/misc/mime.types"
>>text/plain"log"
>> }
>> 
>> httpd(96368): syscall 5 "wpath"
>> httpd(87490): syscall 5 "wpath"
>> httpd(30649): syscall 5 "wpath"
> 
> This very much sounds like "Doctor! Doctor! If I do this it hurts!"
> 
> In case anyone wonders if adding wpath to the pledge would solve this,
> it is not the right solution, also it will not get you very far since
> libcrypto is trying to dick around with /dev/tty. You will probably be
> killed shortly afterwards because of missing tty pledge...
> 

Right, protected private keys are currently not supported. Workarounds wouldn't 
help.

I have ideas how to implement it properly.

> I'm wondering if relayd is handling this better. If yes, we should
> bring over the crypto engine, if no we should fix relayd and then
> bring over the crypto engine.
> 

No, it doesn't handle it better.

Reyk

>> 
>> #0  0x022b9356bc0a in _thread_sys_open () at {standard input}:5
>> #1  0x022b935d6299 in *_libc_open_cancel (path=Variable "path" is not 
>> available.
>> ) at /usr/src/lib/libc/sys/w_open.c:36
>> #2  0x022b9359a642 in *_libc_fopen (file=0x22b2db5c9be "/dev/tty", 
>> mode=Variable "mode" is not available.
>> ) at /usr/src/lib/libc/stdio/fopen.c:54
>> #3  0x022b2d92d26f in open_console (ui=Variable "ui" is not available.
>> ) at /usr/src/lib/libcrypto/ui/ui_openssl.c:304
>> #4  0x022b2d9e65da in UI_process (ui=0x22b217187c0) at 
>> /usr/src/lib/libcrypto/ui/ui_lib.c:455
>> #5  0x022b2d954b8f in EVP_read_pw_string_min (buf=0x7f7f19f0 "", 
>> min=4, len=Variable "len" is not available.
>> ) at /usr/src/lib/libcrypto/evp/evp_key.c:117
>> #6  0x022b2d9dc018 in PEM_def_callback (buf=0x7f7f19f0 "", num=1024, 
>> w=0, key=Variable "key" is not available.
>> ) at /usr/src/lib/libcrypto/pem/pem_lib.c:113
>> #7  0x022b2d9dc2c4 in PEM_do_header (cipher=0x7f7f1ec0,
>>data=0x22bc09b6000 
>> "d\vQ\212\222Åííó\035\006\227\221\004ÛÇ.H\033\225YͧÄ\nmKql}1i\034­PÇåz\033a@Ä\232Ä\220Nÿ\037ÁAPfVs\005r\226ñ\030\2273Tã
>>  W\t\201î ý\217Í+\2033¼괸^\226D\2340z:-+g\226´ã*à\034", plen=0x7f7f1ee8, 
>> callback=Variable "callback" is not available.
>> )
>>at /usr/src/lib/libcrypto/pem/pem_lib.c:447
>> #8  0x022b2d9dc64c in PEM_bytes_read_bio (pdata=0x7f7f1f68, 
>> plen=0x7f7f1f60, pnm=0x7f7f1f78,
>>name=0x22b2db5dcb5 "ANY PRIVATE KEY", bp=0x22b514c9e00, cb=0, u=0x0) at 
>> /usr/src/lib/libcrypto/pem/pem_lib.c:296
>> #9  0x022b2d93112f in PEM_read_bio_PrivateKey (bp=Variable "bp" is not 
>> available.
>> ) at /usr/src/lib/libcrypto/pem/pem_pkey.c:90
>> #10 0x022b6ef43b62 in tls_configure_ssl_keypair (ctx=0x22b514c9e80, 
>> ssl_ctx=0x22bcc86ce00, keypair=0x22b9294df00, required=Variable "required" 
>> is not available.
>> )
>>at /usr/src/lib/libtls/tls.c:347
>> #11 0x022b6ef42135 in tls_configure_server_ssl (ctx=0x22b514c9e80, 
>> ssl_ctx=0x22b514c9eb8, keypair=0x22b9294df00)
>>at /usr/src/lib/libtls/tls_server.c:261
>> #12 0x022b6ef427a1 in tls_configure_server (ctx=0x22b514c9e80) at 
>> /usr/src/lib/libtls/tls_server.c:361
>> #13 0x022920b1413c in server_tls_init (srv=0x22bd885d000) at 
>> /usr/src/usr.sbin/httpd/server.c:297
>> #14 0x022920b1431c in server_launch () at 
>> /usr/src/usr.sbin/httpd/server.c:359
>> #15 0x022920b16759 in server_dispatch_parent (fd=3, p=0x22920d301c0, 
>> imsg=0x7f7f25a0) at /usr/src/usr.sbin/httpd/server.c:1289
>> #16 0x022920b12f99 in proc_dispatch (fd=3, event=2, arg=0x22c1281) 
>> at /usr/src/usr.sbin/httpd/proc.c:652
>> #17 0x022c070a0808 in event_base_loop (base=0x22b94f5d000, 
>> flags=Variable "flags" is not available.
>> ) at /usr/src/lib/libevent/event.c:350
>> #18 0x022920b12db4 in proc_run (ps=0x22c0f506000, p=0x22920d30080, 
>> procs=0x22920d301c0, nproc=2, run=0x22920b1424d ,
>>arg=0x0) at /usr/src/usr.sbin/httpd/proc.c:594
>> #19 0x022920b137b1 in server (ps=0x22c0f506000, p=0x22920d30080) at 
>> /usr/src/usr.sbin/httpd/server.c:87
>> #20 0x022920b11da5 in proc_init (ps=0x22c0f506000, procs=0x22920d30080, 
>> nproc=2, argc=5, argv=0x7f7f2898, proc_id=PROC_SERVER)
>>at /usr/src/usr.sbin/httpd/proc.c:249
>> #21 0x022920b0ac57 in main (argc=0, argv=0x7f7f2898) at 
>> /usr/src/usr.sbin/httpd/httpd.c:218
>> 
> 
> -- 
> I'm not entirely sure you are real.
>

Re: httpd violates pledge with passworded private key

2017-06-07 Thread Sebastien Marie 
On Tue, Jun 06, 2017 at 08:41:04PM +, Florian Obser wrote:
> On Tue, Jun 06, 2017 at 09:18:25PM +1000, Jonathan Gray wrote:
> > when using a server.key with a passphrase, ie
> > 
> > openssl genrsa -aes256 -out /etc/ssl/private/server.key 2048
> > 
> > server "default" {
> > listen on * port 80
> > listen on * tls port 443
> > directory { auto index }
> > }
> > 
> > types {
> > include "/usr/share/misc/mime.types"
> > text/plain  "log"
> > }
> > 
> > httpd(96368): syscall 5 "wpath"
> > httpd(87490): syscall 5 "wpath"
> > httpd(30649): syscall 5 "wpath"
> 
> This very much sounds like "Doctor! Doctor! If I do this it hurts!"
> 
> In case anyone wonders if adding wpath to the pledge would solve this,
> it is not the right solution, also it will not get you very far since
> libcrypto is trying to dick around with /dev/tty. You will probably be
> killed shortly afterwards because of missing tty pledge...
> 
> I'm wondering if relayd is handling this better. If yes, we should
> bring over the crypto engine, if no we should fix relayd and then
> bring over the crypto engine.

does libtls have some option to tell libcrypto to not try interactive
asking password ? it seems to be the underline problem.

> > 
> > #0  0x022b9356bc0a in _thread_sys_open () at {standard input}:5
> > #1  0x022b935d6299 in *_libc_open_cancel (path=Variable "path" is not 
> > available.
> > ) at /usr/src/lib/libc/sys/w_open.c:36
> > #2  0x022b9359a642 in *_libc_fopen (file=0x22b2db5c9be "/dev/tty", 
> > mode=Variable "mode" is not available.
> > ) at /usr/src/lib/libc/stdio/fopen.c:54
> > #3  0x022b2d92d26f in open_console (ui=Variable "ui" is not available.
> > ) at /usr/src/lib/libcrypto/ui/ui_openssl.c:304
> > #4  0x022b2d9e65da in UI_process (ui=0x22b217187c0) at 
> > /usr/src/lib/libcrypto/ui/ui_lib.c:455
> > #5  0x022b2d954b8f in EVP_read_pw_string_min (buf=0x7f7f19f0 "", 
> > min=4, len=Variable "len" is not available.
> > ) at /usr/src/lib/libcrypto/evp/evp_key.c:117
> > #6  0x022b2d9dc018 in PEM_def_callback (buf=0x7f7f19f0 "", 
> > num=1024, w=0, key=Variable "key" is not available.
> > ) at /usr/src/lib/libcrypto/pem/pem_lib.c:113
> > #7  0x022b2d9dc2c4 in PEM_do_header (cipher=0x7f7f1ec0,
> > data=0x22bc09b6000 
> > "d\vQ\212\222Åííó\035\006\227\221\004ÛÇ.H\033\225YͧÄ\nmKql}1i\034­PÇåz\033a@Ä\232Ä\220Nÿ\037ÁAPfVs\005r\226ñ\030\2273Tã
> >  W\t\201î ý\217Í+\2033¼괸^\226D\2340z:-+g\226´ã*à\034", plen=0x7f7f1ee8, 
> > callback=Variable "callback" is not available.
> > )
> > at /usr/src/lib/libcrypto/pem/pem_lib.c:447
> > #8  0x022b2d9dc64c in PEM_bytes_read_bio (pdata=0x7f7f1f68, 
> > plen=0x7f7f1f60, pnm=0x7f7f1f78,
> > name=0x22b2db5dcb5 "ANY PRIVATE KEY", bp=0x22b514c9e00, cb=0, u=0x0) at 
> > /usr/src/lib/libcrypto/pem/pem_lib.c:296
> > #9  0x022b2d93112f in PEM_read_bio_PrivateKey (bp=Variable "bp" is not 
> > available.
> > ) at /usr/src/lib/libcrypto/pem/pem_pkey.c:90
> > #10 0x022b6ef43b62 in tls_configure_ssl_keypair (ctx=0x22b514c9e80, 
> > ssl_ctx=0x22bcc86ce00, keypair=0x22b9294df00, required=Variable "required" 
> > is not available.
> > )
> > at /usr/src/lib/libtls/tls.c:347
> > #11 0x022b6ef42135 in tls_configure_server_ssl (ctx=0x22b514c9e80, 
> > ssl_ctx=0x22b514c9eb8, keypair=0x22b9294df00)
> > at /usr/src/lib/libtls/tls_server.c:261
> > #12 0x022b6ef427a1 in tls_configure_server (ctx=0x22b514c9e80) at 
> > /usr/src/lib/libtls/tls_server.c:361
> > #13 0x022920b1413c in server_tls_init (srv=0x22bd885d000) at 
> > /usr/src/usr.sbin/httpd/server.c:297
> > #14 0x022920b1431c in server_launch () at 
> > /usr/src/usr.sbin/httpd/server.c:359
> > #15 0x022920b16759 in server_dispatch_parent (fd=3, p=0x22920d301c0, 
> > imsg=0x7f7f25a0) at /usr/src/usr.sbin/httpd/server.c:1289
> > #16 0x022920b12f99 in proc_dispatch (fd=3, event=2, arg=0x22c1281) 
> > at /usr/src/usr.sbin/httpd/proc.c:652
> > #17 0x022c070a0808 in event_base_loop (base=0x22b94f5d000, 
> > flags=Variable "flags" is not available.
> > ) at /usr/src/lib/libevent/event.c:350
> > #18 0x022920b12db4 in proc_run (ps=0x22c0f506000, p=0x22920d30080, 
> > procs=0x22920d301c0, nproc=2, run=0x22920b1424d ,
> > arg=0x0) at /usr/src/usr.sbin/httpd/proc.c:594
> > #19 0x022920b137b1 in server (ps=0x22c0f506000, p=0x22920d30080) at 
> > /usr/src/usr.sbin/httpd/server.c:87
> > #20 0x022920b11da5 in proc_init (ps=0x22c0f506000, procs=0x22920d30080, 
> > nproc=2, argc=5, argv=0x7f7f2898, proc_id=PROC_SERVER)
> > at /usr/src/usr.sbin/httpd/proc.c:249
> > #21 0x022920b0ac57 in main (argc=0, argv=0x7f7f2898) at 
> > /usr/src/usr.sbin/httpd/httpd.c:218
> > 
> 
> -- 
> I'm not entirely sure you are real.
> 

-- 
Sebastien Marie