DaemonForums  

Go Back   DaemonForums > OpenBSD > OpenBSD Security

OpenBSD Security Functionally paranoid!

Reply
 
Thread Tools Display Modes
  #1   (View Single Post)  
Old 11th May 2019
bsdcord bsdcord is offline
Port Guard
 
Join Date: Apr 2019
Posts: 23
Default about the kernel

Hi,
I have some questions about the kernel security.
1) How can I check the integrity of the kernel ?
2) how can I know if it's trusted ?
3) How can I detect malicious kernel modules ?
4) How can I see the kernel modules loaded ?

Thank you.
Reply With Quote
  #2   (View Single Post)  
Old 11th May 2019
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,977
Default

  1. The sha256(1) message digest of of the kernels and filesets shipped by the Project is signed with signify(1).
  2. You can use signify() on any system where it is installed. It is open source, and available with other BSDs and some Linux distributions.
  3. You must trust the project to protect the signify() private keys, you must either understand or trust the SHA-1 cryptographic primitive, and either understand or trust the sha256() utility that uses it. In like manner, you must understand or trust the signify() utility.
  4. OpenBSD uses a monolithic kernel, and does not support any kernel modules.
  5. See #4 above.
Reply With Quote
  #3   (View Single Post)  
Old 11th May 2019
bsdcord bsdcord is offline
Port Guard
 
Join Date: Apr 2019
Posts: 23
Default

1) But if the kernel is installed and relinked, the sha256 digest is not the original.. I mean the original fileset kernel is different from the installed one. Isn'it ?
2) How can I use signify to check the installed kernel ? Or maybe do I have signified manually the kernel before ?
Reply With Quote
  #4   (View Single Post)  
Old 11th May 2019
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,977
Default

Quote:
Originally Posted by bsdcord View Post
1) But if the kernel is installed and relinked, the sha256 digest is not the original.. I mean the original fileset kernel is different from the installed one. Isn'it ?
Correct. In the event of an break in either the checksum chain or a failure to build a new kernel, notice is sent to the console and syslog(3).
Quote:
2) How can I use signify to check the installed kernel ? Or maybe do I have signified manually the kernel before ?
Before. See the EXAMPLES section in the signify(1) man page. And, an example verification of a new bsd.rd RAMDISK kernel is shown in the Upgrade Guide for every new release. The RAMDISK's install or upgrade script will use signify() to verify every kernel and fileset.
Reply With Quote
  #5   (View Single Post)  
Old 11th May 2019
bsdcord bsdcord is offline
Port Guard
 
Join Date: Apr 2019
Posts: 23
Default

Let me know if I have understood.
I install openbsd and I use signify to check if the kernel from the iso is trusted. Then during the installation is create a new kernel with its digest.
Then at every boot the kernel create a sha256 digest for the next boot and every boot check the digest created before. If something was been altered I see it in the console during the boot.
The digest of the running kernel is in /var/db/kernel.SHA256
and the digest of the next boot where is ?

An other question: can an attacker create a new relinked kernel with its digest ?
Reply With Quote
  #6   (View Single Post)  
Old 11th May 2019
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,977
Default

Quote:
Originally Posted by bsdcord View Post
...I install openbsd and I use signify to check if the kernel from the iso is trusted.
Not just from an .iso. From any install media available to the architecture: optical, diskette, tape, disk drive (including stick), or from the network.
Quote:
Then during the installation is create a new kernel with its digest.
Correct.
Quote:
Then at every boot the kernel create a sha256 digest for the next boot and every boot check the digest created before. If something was been altered I see it in the console during the boot.
Correct.
Quote:
The digest of the running kernel is in /var/db/kernel.SHA256
and the digest of the next boot where is ?
In the next kernel. See /usr/libexec/reorder_kernel and /usr/share/relink/kernel/Makefile.
Quote:
An other question: can an attacker create a new relinked kernel with its digest ?
I don't know. Now, it's your turn: First, determine how to break the integrity chain. Then, propose an alternative solution to the tech@ mailing list.
Reply With Quote
  #7   (View Single Post)  
Old 11th May 2019
bsdcord bsdcord is offline
Port Guard
 
Join Date: Apr 2019
Posts: 23
Default

I'm not a kernel developper but:
  • the 80% of times I boot my laptop I don't see my console because I am distracted. And if I understood well the os continue the boot. IMHO, if the kernel is altered should'nt boot.
  • If I understand the Makefile, all the *.o are piece of compiled code, should be pretty easy add an extraneous object and built in the new kernel.
  • if the kernel is altered, imho the kernel say and does what the attacker says. The attacker can upload a new kernel and substitute /bsd and the new kernel at the next boot will say the digest chain is ok. I mean the kernel rootkit should be developed to say everything is ok.
Maybe I made it too easy because I am not a developer.
Reply With Quote
  #8   (View Single Post)  
Old 11th May 2019
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,977
Default

Quote:
... should be pretty easy add an extraneous object ...
The directory is only writable by the superuser.

If you have an attacker with root access, you have many more problems than just ensuring kernel integrity.
Reply With Quote
  #9   (View Single Post)  
Old 11th May 2019
bsdcord bsdcord is offline
Port Guard
 
Join Date: Apr 2019
Posts: 23
Default

yeah, of course the attacker has the root, a kernel rootkit generally is used to have the total control of the victim machine, after a break in.
Many more problems ? I don't think there is a something more important than the kernel integrity.
A userland rootkit is very easy to detect, a kernel rootkit less. Especially if is inside the kernel and the kernel change hash every time I boot.
Reply With Quote
Old 12th May 2019
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,977
Default

This forum is not associated with the OpenBSD Project, and is primarily a community of users. I'm just another user.
  • If you want to discuss your concerns with OpenBSD kernel developers, please use the misc@ mailing list.
  • Should you develop any improvements to kernel management tools, or develop new components for the tool chain that you'd like to share, please submit them to the tech@ mailing list for consideration by the Project.
  • Should you discover a vulnerability in the current technology, the Project would welcome your notification through the security@ email address.
Reply With Quote
Old 12th May 2019
e1-531g e1-531g is offline
ISO Quartermaster
 
Join Date: Mar 2014
Posts: 628
Default

I think there is some trade-off between protecting the kernel via anti-exploit mitigation vs checking integrity of file with kernel executable for signs of infections via i.e. booting from external media such as DVD disc and inspecting files.

Quote:
I understand the Makefile, all the *.o are piece of compiled code
Does OpenBSD saves hashes of these files somewhere? I mean individual *.o files. It may be some way to inspect whether there was an infection of kernel.
__________________
Signature: Furthermore, I consider that systemd must be destroyed.
Based on Latin oratorical phrase
Reply With Quote
Old 12th May 2019
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,977
Default

Quote:
Originally Posted by e1-531g View Post
...Does OpenBSD saves hashes of these files somewhere? I mean individual *.o files...
Indirectly, only. They are installed via unpacking /usr/share/relink/kernel.tgz, which is included in the signed baseXX.tgz fileset. Binary updates through syspatch(8) maintain this integrity chain through signify(1). Any kernel patches applied by building from source code -- for example, applying a -stable patch which does not qualify for errata publication -- can't be signed by the Project so any integrity controls must be applied by local administration.
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
ZFS for the Linux kernel J65nko News 0 7th June 2010 06:43 PM
6.3 > 7.2 kernel errors carpman FreeBSD Installation and Upgrading 3 16th March 2010 10:58 PM
kernel modules Mr-Biscuit FreeBSD General 0 2nd March 2009 06:18 AM
The kernel is angry! Weaseal FreeBSD Installation and Upgrading 17 4th August 2008 10:15 AM
Linux Kernel map TerryP Other BSD and UNIX/UNIX-like 2 1st July 2008 05:33 AM


All times are GMT. The time now is 10:56 PM.


Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Content copyright © 2007-2010, the authors
Daemon image copyright ©1988, Marshall Kirk McKusick