Re: Removing FUSE would theoretically make a system more secure?

2018-01-28 Thread who one
Hello, 

"> And what are you defending against?"

there was/is a great guy that investigated the security of the BSDs, reported a 
few bugs too: 

https://www.youtube.com/watch?v=rRg2vuwF1hY=youtu.be=1522

that lead to ex.: 

https://ftp.openbsd.org/pub/OpenBSD/patches/6.1/common/017_fuse.patch.sig

So would the mentioned method, by removing the "grep -i fuse /sys/conf/GENERIC" 
and doing re-compile would "disable FUSE"? 

Thanks for the syspatch/relinking hint, I forgot about them if I touch the 
kernel!

Thanks!


> Sent: Sunday, January 28, 2018 at 5:15 AM
> From: mar...@martinbrandenburg.com
> To: misc@openbsd.org, whoonet...@mail.com
> Subject: Re: Removing FUSE would theoretically make a system more secure?
>
> > afaik if I would remove the lines that contains "FUSE" and "fuse" from 
> > /sys/conf/GENERIC and re-compile the kernel, that would mean, there will be 
> > no more FUSE support in my kernel after reboot.
> >
> > If so, would this step help to make my system more secure? Ex.: from a 
> > future FUSE related security issue? 
> >
> > just asking theoretically, since I don't use FUSE related stuff, so 
> > thinking of that is unneeded. 
> >
> > or it would just create an unsupported kernel which didn't had any tests 
> > regarding the missing fuse and maybe cause bigger issues and security 
> > issues vs. if I wouldn't touched it? 
> 
> I daresay that removing FUSE support will make you invulnerable to any
> kind of bug in FUSE.  jca has already given you an outline of the
> reasons to believe such a bug, if it exists, is rather unlikely to be
> exploitable.
> 
> You had better consider what you're giving up when you make this change.
> You won't be able to use FUSE.  You won't be able to use syspatch.  I'm
> not sure how it affects kernel relinking.  You'll have to build your
> kernels yourself on all architectures you run for each release and every
> kernel-related erratum.  You'll have to maintain your changes.  You
> can't just say "I'm not sure" as I just did.  You'll have to take
> responsibility for the possibility that running a non-standard
> configuration may introduce bugs.
> 
> And what are you defending against?  Somebody has to get root or a way
> to mount filesystems without root.  We'll assume he's got a way to mount
> filesystems without root, because if he had a way to get root, he
> wouldn't need bother with anything else.  Then he's got to have his FUSE
> exploit which gives him root.  Since he probably doesn't have an account
> on your system, he's got to have a third exploit to start running code
> to begin with.
> 
> Defense in depth is good, but this isn't worth the effort on your part.
> 
> Your security need only be good enough to require an attacker spend more
> than he's willing to spend.
> 
> Martin
> 
> 



Removing FUSE would theoretically make a system more secure?

2018-01-27 Thread who one
Hello, 

afaik if I would remove the lines that contains "FUSE" and "fuse" from 
/sys/conf/GENERIC and re-compile the kernel, that would mean, there will be no 
more FUSE support in my kernel after reboot.

If so, would this step help to make my system more secure? Ex.: from a future 
FUSE related security issue? 

just asking theoretically, since I don't use FUSE related stuff, so thinking of 
that is unneeded. 

or it would just create an unsupported kernel which didn't had any tests 
regarding the missing fuse and maybe cause bigger issues and security issues 
vs. if I wouldn't touched it? 

Many thanks!



Re: OpenBSD !HTTPS websites - why?

2018-01-24 Thread who one
Hello, 

> hosted on various machines run by different people. I'm not sure if
> there's any viable way to handle keys and certificates for this type
> of situation.

-->>

###
letsencrypt: 

Can one domain have multiple servers controlled by different entities

Yes, but there will need to be some coordination for getting the SSL 
certificates
How can the coordination work (depends on the ACME challenge used)

HTTP

Working together

Whenever one of the 2 hosts wants to renew a cert they would need to 
deploy a .well_known file to both servers, so that no matter which one 
letsencrypt access they get the right file.

Centralised

You can run an additional server, which both parties can push files to, 
and have both servers redirect any requests for .well_known to this server
DNS

Full access

Either of the 2 hosts would need to be able to add DNS records to pass 
the checks

Custom API

An API can be setup so that the 2 hosts can submit an ACME response and 
have it served

Limiting impact of breaches

As the servers need to be able to generate SSL certificates if they are 
breached they will be able to generate certs.

Using Must-Staple ( https://scotthelme.co.uk/ocsp-must-staple/ ) the impact of 
current certs leaking can be reduced, but this will not help if the host is 
instructed to make new certs without this after generation.

Using CT logs you can watch for invalid certs, and using CAA you can limit 
which CAs will issue certs, which will help reduce the breach impact.

You could even use CAA to disable certs entirely, and only allow issuance by 
contacting you and manually removing the record until the cert has been issued, 
reducing your attack window, but increasing the management overhead.

###

> Sent: Monday, January 15, 2018 at 1:37 PM
> From: "Stuart Henderson" <s...@spacehopper.org>
> To: misc@openbsd.org
> Subject: Re: OpenBSD !HTTPS websites - why?
>
> On 2018-01-15, who one <whoonet...@mail.com> wrote:
> > Hello, 
> >
> > http://www.openbsdfoundation.org/
> > http://firmware.openbsd.org/firmware/
> >
> > When can we have HTTPS connection on these websites? 
> >
> > What website remains that doesn't have HTTPS yet and related to OpenBSD? 
> >
> > Security should be in layers, HTTPS is one additional layer. 
> >
> > 70% of the websites in the world uses HTTPS: https://letsencrypt.org/stats/ 
> > , see "Percentage of Web Pages Loaded by Firefox Using HTTPS". If OpenBSD 
> > is security oriented, HTTPS should be de facto. 
> >
> > Many thanks.
> >
> >
> 
> I can't speak for openbsdfoundation, but for firmware.openbsd.org it's
> hosted on various machines run by different people. I'm not sure if
> there's any viable way to handle keys and certificates for this type
> of situation.
> 
> Firmware packages do have signify(1) signatures themselves. These
> are verified early - before passing to gzip to decompress them.
> However there is a remaining issue that a MITM could suppress
> certain packages, or provide older signed versions.
> 
> 
> 



Re: Kernel panic with openbsd 6.2

2018-01-24 Thread who one
Could it be related to: 
https://newsroom.intel.com/news/root-cause-of-reboot-issue-identified-updated-guidance-for-customers-and-partners/

?

> Sent: Friday, January 19, 2018 at 9:50 PM
> From: "Mik J" 
> To: Misc 
> Subject: Kernel panic with openbsd 6.2
>
> Hello,
> 
> I had many kernel panic these past days. This is a 6.2 openbsd VM running on 
> esxi 5.5
> 
> I took screenshots then followed
> https://www.openbsd.org/ddb.html
> 
> # objdump -dlr /sys/arch/amd64/compile/GENERIC.MP/obj/if_vmx.o > 
> /tmp/if_vmx.dis
> 
> # grep "" /tmp/if_vmx.dis
>     10f6:   e8 d5 00 00 00  callq  11d0 
>     1176:   e8 55 00 00 00  callq  11d0 
> 11d0 :
>     1857:   e8 74 f9 ff ff  callq  11d0 
> 
> # grep -n 10f6 /tmp/if_vmx.dis
> 1667:    10f6:  e8 d5 00 00 00  callq  11d0 
> 
> # grep ":" /tmp/if_vmx.dis
> 11d0 :
> 
> # printf '%x\n' $((0x11d0 + 0x263))
> 1433
> 
> vi /tmp/if_vmx.dis
>    2040 1433:   ba 01 00 00 00  mov    $0x1,%edx
> I find is on line 2040
> 
> => But the file is only 1251 line long
> nl -ba /sys/dev/pci/if_vmx.c | sed -n 2040p
> 
> => So that last command gives me nothing
> 
> Do you have an idea of what mistake I did so that I can make a report ?
> 
> Thank you
> 
>



Re: History documentation

2018-01-24 Thread who one
Hey, strange, there is 5.3 in 
https://cloudflare.cdn.openbsd.org/pub/OpenBSD/doc/history/

is this still maintained?

Many thanks. 

> Sent: Saturday, January 20, 2018 at 1:21 PM
> From: mazocomp 
> To: misc@openbsd.org
> Subject: History documentation
>
> Hi!
> Both obsd-faq.txt and pf-faq.txt in pub/OpenBSD/doc/ are same as
> obsd-faq52.txt and pf-faq52.txt in pub/OpenBSD/doc/history/
> So I wonder is there a point to keep them out of date?
> 
> 



OpenBSD !HTTPS websites - why?

2018-01-15 Thread who one
Hello, 

http://www.openbsdfoundation.org/
http://firmware.openbsd.org/firmware/

When can we have HTTPS connection on these websites? 

What website remains that doesn't have HTTPS yet and related to OpenBSD? 

Security should be in layers, HTTPS is one additional layer. 

70% of the websites in the world uses HTTPS: https://letsencrypt.org/stats/ , 
see "Percentage of Web Pages Loaded by Firefox Using HTTPS". If OpenBSD is 
security oriented, HTTPS should be de facto. 

Many thanks.



Re: Community-driven OpenBSD tutorials wiki?

2018-01-05 Thread who one
imho use the official documentation, not separated wiki. this is the right way. 

> Sent: Friday, January 05, 2018 at 8:32 PM
> From: "Karel Gardas" 
> To: "Andreas Thulin" 
> Cc: "misc@openbsd.org" 
> Subject: Re: Community-driven OpenBSD tutorials wiki?
>
> On Thu, 04 Jan 2018 14:17:51 +
> Andreas Thulin  wrote:
> 
> > Hi all!
> > 
> > Thought I'd create an OpenBSD wiki somewhere, where anyone (especially
> > non-developers like myself) could create and edit tutorials for stuff
> > non-developers like myself would find useful. I find that sometimes
> > existing tutorials become outdated, and was thinking that a wiki would make
> > updates easier.
> 
> Not bad idea, but when speaking about OpenBSD I would rather recommend to 
> update/fix/enhance OpenBSD's own man collection.
> 
> 



Re: Kernel memory leaking on Intel CPUs?

2018-01-05 Thread who one
sorry, didn't sent my original mail in plaintext

Google came out with a more detailed explanation: 

https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html

Any hardening setting should be enabled? Or code needs to be updated? What is 
the advise for OpenBSD? 

Thanks, 

> Subject: Kernel memory leaking on Intel CPUs?

> https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/
>  
> "It is understood the bug is present in modern Intel processors produced in 
> the past decade. It allows normal user programs – from database applications 
> to JavaScript in web browsers – to discern to some extent the layout or 
> contents of protected kernel memory areas."
> 
> "The fix is to separate the kernel's memory completely from user processes 
> using what's called Kernel Page Table Isolation, or KPTI. At one point, 
> Forcefully Unmap Complete Kernel With Interrupt Trampolines, aka FUCKWIT, was 
> mulled by the Linux kernel team, giving you an idea of how annoying this has 
> been for the developers."
>  
> "AMD processors are not subject"
>  
> https://www.postgresql.org/message-id/2018010354.qikjmf7dvnjgb...@alap3.anarazel.de
>  
> Did anyone hear about this?



Kernel memory leaking on Intel CPUs?

2018-01-03 Thread who one
https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/ "It is
understood the bug is present in modern Intel processors produced in the
past decade. It allows normal user programs – from database applications
to JavaScript in web browsers – to discern to some extent the layout or
contents of protected kernel memory areas." "The fix is to separate the
kernel's memory completely from user processes using what's called Kernel
Page Table Isolation, or KPTI. At one point, Forcefully Unmap Complete
Kernel With Interrupt Trampolines, aka FUCKWIT, was mulled by the Linux
kernel team, giving you an idea of how annoying this has been for the
developers." "AMD processors are not subject"
https://www.postgresql.org/message-id/2018010354.qikjmf7dvnjgb...@alap3.anarazel.de
Did anyone hear about this?