httpd violates pledge with passworded private key

Discussion:

Jonathan Gray

2017-06-06 11:18:25 UTC

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"

#0 0x0000022b9356bc0a in _thread_sys_open () at {standard input}:5
#1 0x0000022b935d6299 in *_libc_open_cancel (path=Variable "path" is not available.
) at /usr/src/lib/libc/sys/w_open.c:36
#2 0x0000022b9359a642 in *_libc_fopen (file=0x22b2db5c9be "/dev/tty", mode=Variable "mode" is not available.
) at /usr/src/lib/libc/stdio/fopen.c:54
#3 0x0000022b2d92d26f in open_console (ui=Variable "ui" is not available.
) at /usr/src/lib/libcrypto/ui/ui_openssl.c:304
#4 0x0000022b2d9e65da in UI_process (ui=0x22b217187c0) at /usr/src/lib/libcrypto/ui/ui_lib.c:455
#5 0x0000022b2d954b8f in EVP_read_pw_string_min (buf=0x7f7fffff19f0 "", min=4, len=Variable "len" is not available.
) at /usr/src/lib/libcrypto/evp/evp_key.c:117
#6 0x0000022b2d9dc018 in PEM_def_callback (buf=0x7f7fffff19f0 "", num=1024, w=0, key=Variable "key" is not available.
) at /usr/src/lib/libcrypto/pem/pem_lib.c:113
#7 0x0000022b2d9dc2c4 in PEM_do_header (cipher=0x7f7fffff1ec0,
data=0x22bc09b6000 "d\vQ\212\222Åííó\035\006\227\221\004ÛÇ.H\033\225YͧÄ\nmKql}1i\034PÇåz\033a@Ä\232Ä\220Nÿ\037ÁAPfVs\005r\226ñ\030\2273Tã W\t\201î ý\217Í+\2033¼괸^\226D\2340z:-+g\226´ã*à\034", plen=0x7f7fffff1ee8, callback=Variable "callback" is not available.
)
at /usr/src/lib/libcrypto/pem/pem_lib.c:447
#8 0x0000022b2d9dc64c in PEM_bytes_read_bio (pdata=0x7f7fffff1f68, plen=0x7f7fffff1f60, pnm=0x7f7fffff1f78,
name=0x22b2db5dcb5 "ANY PRIVATE KEY", bp=0x22b514c9e00, cb=0, u=0x0) at /usr/src/lib/libcrypto/pem/pem_lib.c:296
#9 0x0000022b2d93112f in PEM_read_bio_PrivateKey (bp=Variable "bp" is not available.
) at /usr/src/lib/libcrypto/pem/pem_pkey.c:90
#10 0x0000022b6ef43b62 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 0x0000022b6ef42135 in tls_configure_server_ssl (ctx=0x22b514c9e80, ssl_ctx=0x22b514c9eb8, keypair=0x22b9294df00)
at /usr/src/lib/libtls/tls_server.c:261
#12 0x0000022b6ef427a1 in tls_configure_server (ctx=0x22b514c9e80) at /usr/src/lib/libtls/tls_server.c:361
#13 0x0000022920b1413c in server_tls_init (srv=0x22bd885d000) at /usr/src/usr.sbin/httpd/server.c:297
#14 0x0000022920b1431c in server_launch () at /usr/src/usr.sbin/httpd/server.c:359
#15 0x0000022920b16759 in server_dispatch_parent (fd=3, p=0x22920d301c0, imsg=0x7f7fffff25a0) at /usr/src/usr.sbin/httpd/server.c:1289
#16 0x0000022920b12f99 in proc_dispatch (fd=3, event=2, arg=0x22c12810000) at /usr/src/usr.sbin/httpd/proc.c:652
#17 0x0000022c070a0808 in event_base_loop (base=0x22b94f5d000, flags=Variable "flags" is not available.
) at /usr/src/lib/libevent/event.c:350
#18 0x0000022920b12db4 in proc_run (ps=0x22c0f506000, p=0x22920d30080, procs=0x22920d301c0, nproc=2, run=0x22920b1424d <server_init>,
arg=0x0) at /usr/src/usr.sbin/httpd/proc.c:594
#19 0x0000022920b137b1 in server (ps=0x22c0f506000, p=0x22920d30080) at /usr/src/usr.sbin/httpd/server.c:87
#20 0x0000022920b11da5 in proc_init (ps=0x22c0f506000, procs=0x22920d30080, nproc=2, argc=5, argv=0x7f7fffff2898, proc_id=PROC_SERVER)
at /usr/src/usr.sbin/httpd/proc.c:249
#21 0x0000022920b0ac57 in main (argc=0, argv=0x7f7fffff2898) at /usr/src/usr.sbin/httpd/httpd.c:218

Florian Obser

2017-06-06 20:41:04 UTC

Permalink

Post by Jonathan Gray
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.

Post by Jonathan Gray
#0 0x0000022b9356bc0a in _thread_sys_open () at {standard input}:5
#1 0x0000022b935d6299 in *_libc_open_cancel (path=Variable "path" is not available.
) at /usr/src/lib/libc/sys/w_open.c:36
#2 0x0000022b9359a642 in *_libc_fopen (file=0x22b2db5c9be "/dev/tty", mode=Variable "mode" is not available.
) at /usr/src/lib/libc/stdio/fopen.c:54
#3 0x0000022b2d92d26f in open_console (ui=Variable "ui" is not available.
) at /usr/src/lib/libcrypto/ui/ui_openssl.c:304
#4 0x0000022b2d9e65da in UI_process (ui=0x22b217187c0) at /usr/src/lib/libcrypto/ui/ui_lib.c:455
#5 0x0000022b2d954b8f in EVP_read_pw_string_min (buf=0x7f7fffff19f0 "", min=4, len=Variable "len" is not available.
) at /usr/src/lib/libcrypto/evp/evp_key.c:117
#6 0x0000022b2d9dc018 in PEM_def_callback (buf=0x7f7fffff19f0 "", num=1024, w=0, key=Variable "key" is not available.
) at /usr/src/lib/libcrypto/pem/pem_lib.c:113
#7 0x0000022b2d9dc2c4 in PEM_do_header (cipher=0x7f7fffff1ec0,
)
at /usr/src/lib/libcrypto/pem/pem_lib.c:447
#8 0x0000022b2d9dc64c in PEM_bytes_read_bio (pdata=0x7f7fffff1f68, plen=0x7f7fffff1f60, pnm=0x7f7fffff1f78,
name=0x22b2db5dcb5 "ANY PRIVATE KEY", bp=0x22b514c9e00, cb=0, u=0x0) at /usr/src/lib/libcrypto/pem/pem_lib.c:296
#9 0x0000022b2d93112f in PEM_read_bio_PrivateKey (bp=Variable "bp" is not available.
) at /usr/src/lib/libcrypto/pem/pem_pkey.c:90
#10 0x0000022b6ef43b62 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 0x0000022b6ef42135 in tls_configure_server_ssl (ctx=0x22b514c9e80, ssl_ctx=0x22b514c9eb8, keypair=0x22b9294df00)
at /usr/src/lib/libtls/tls_server.c:261
#12 0x0000022b6ef427a1 in tls_configure_server (ctx=0x22b514c9e80) at /usr/src/lib/libtls/tls_server.c:361
#13 0x0000022920b1413c in server_tls_init (srv=0x22bd885d000) at /usr/src/usr.sbin/httpd/server.c:297
#14 0x0000022920b1431c in server_launch () at /usr/src/usr.sbin/httpd/server.c:359
#15 0x0000022920b16759 in server_dispatch_parent (fd=3, p=0x22920d301c0, imsg=0x7f7fffff25a0) at /usr/src/usr.sbin/httpd/server.c:1289
#16 0x0000022920b12f99 in proc_dispatch (fd=3, event=2, arg=0x22c12810000) at /usr/src/usr.sbin/httpd/proc.c:652
#17 0x0000022c070a0808 in event_base_loop (base=0x22b94f5d000, flags=Variable "flags" is not available.
) at /usr/src/lib/libevent/event.c:350
#18 0x0000022920b12db4 in proc_run (ps=0x22c0f506000, p=0x22920d30080, procs=0x22920d301c0, nproc=2, run=0x22920b1424d <server_init>,
arg=0x0) at /usr/src/usr.sbin/httpd/proc.c:594
#19 0x0000022920b137b1 in server (ps=0x22c0f506000, p=0x22920d30080) at /usr/src/usr.sbin/httpd/server.c:87
#20 0x0000022920b11da5 in proc_init (ps=0x22c0f506000, procs=0x22920d30080, nproc=2, argc=5, argv=0x7f7fffff2898, proc_id=PROC_SERVER)
at /usr/src/usr.sbin/httpd/proc.c:249
#21 0x0000022920b0ac57 in main (argc=0, argv=0x7f7fffff2898) at /usr/src/usr.sbin/httpd/httpd.c:218

--
I'm not entirely sure you are real.

Sebastien Marie

2017-06-07 06:52:31 UTC

Permalink

Post by Florian Obser

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.

Post by Florian Obser

--
I'm not entirely sure you are real.

--
Sebastien Marie

Reyk Floeter

2017-06-07 08:35:38 UTC

Permalink

Post by Florian Obser

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

I have ideas how to implement it properly.

Post by Florian Obser
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

Post by Florian Obser

--
I'm not entirely sure you are real.

Ted Unangst

2017-06-07 18:06:42 UTC

Permalink

Post by Jonathan Gray
when using a server.key with a passphrase, ie
) at /usr/src/lib/libc/stdio/fopen.c:54
#3 0x0000022b2d92d26f in open_console (ui=Variable "ui" is not available.
) at /usr/src/lib/libcrypto/ui/ui_openssl.c:304
#6 0x0000022b2d9dc018 in PEM_def_callback
) at /usr/src/lib/libcrypto/pem/pem_lib.c:113
#10 0x0000022b6ef43b62 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().

Joel Sing

2017-06-10 14:13:14 UTC

Permalink

Post by Ted Unangst

Yes, it is a bug in libtls, however it is moreso a bug in libcrypto - that's
what is trying to gain a passphrase via the console/stdin. We can hack around
it and disable it in libtls.

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

I'm not sure that I'd consider that sane. We already have tls_load_file() for
this purpose, although admittedly the API there could probably be friendlier.
Do we really want tls_configure_keypair() to become "maybe encrypted, maybe
unencrypted"? I'm not convinced that we should really be making libtls expect
to be dealing with encrypted keys at that point.

Ted Unangst

2017-06-10 19:25:18 UTC

Permalink

Post by Joel Sing

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

oh, i think the current API is fine. tls_load_file is the function i was
proposing we add. :)