Syslinux - Dec 2005 - problem with PXElinux and security of local LAN

Hi.

I want to use PXELinux to build a dynamic boot menu for a computer lab. 
  Sometimes, the machines need to be in Linux mode/Windows mode/allow 
the option of Linux/Windows.  I configured this all fine with PXELinux. 
  My problem is really one of security.  Someone can plug in a laptop 
with a DHCP server, and tftp server and fake a lab machine to boot into 
any mode they desire, or even worse, they could configure the local 
machine to boot Linux in single user mode, and hence allow access to 
root, local ssh keys, etc.  I can't really think of any easy way how to 
solve this problem since there is no way to authenticate the PXELinux 
instance that is loading or the configuration files.   Any ideas?  A 
locally configured grub could do the same thing, of course, but using 
pxelinux, I can change the configuration of machines that are off so 
that when they come back on, they are in the mode that I desire.

:(

Jason.

Here is an ideal solution. I dont know how much of this is really possible.

(1) Set your BIOS to boot from the local hard disk.
(2) Use SYSLINUX as your boot loader and run a COMBOOT code (stored in 
your hard disk)
(3) The COMBOOT Code figures out Who the DHCP server it is talking to, 
and has some kind of check.
(4) If check works out, then chain boot your PXE ROM

First this is essentially security by obscurity, i.e. in step (3), I am 
assuming that the DHCP server sends an additional string X
(actually COMBOOT code asks the DHCP server for X). There is some magic 
string hard wired into the COMBOOT code,
which gets encrypted using the current date as the key. If the encrypted 
string is X then you can trust the DHCP server.
If the bad guy finds out the magic string (which is never sent over the 
network), then there is no security left.

It would be cool if this can be implemented. One real life situation 
where SYSLINUX on HDD beats other boot loaders.

- Murali

Jason Keltz wrote:
> Hi.
>
> I want to use PXELinux to build a dynamic boot menu for a computer 
> lab.  Sometimes, the machines need to be in Linux mode/Windows 
> mode/allow the option of Linux/Windows.  I configured this all fine 
> with PXELinux.  My problem is really one of security.  Someone can 
> plug in a laptop with a DHCP server, and tftp server and fake a lab 
> machine to boot into any mode they desire, or even worse, they could 
> configure the local machine to boot Linux in single user mode, and 
> hence allow access to root, local ssh keys, etc.  I can't really think 
> of any easy way how to solve this problem since there is no way to 
> authenticate the PXELinux instance that is loading or the 
> configuration files.   Any ideas?  A locally configured grub could do 
> the same thing, of course, but using pxelinux, I can change the 
> configuration of machines that are off so that when they come back on, 
> they are in the mode that I desire.
>
> :(
>
> Jason.
>
> _______________________________________________
> SYSLINUX mailing list
> Submissions to SYSLINUX at zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux
> Please do not send private replies to mailing list traffic.
>
>

Hi,

Could you not just use menu and set passwords?

MENU PASSWD passwd

	(Only valid after a LABEL statement.)
	Sets a password on this menu entry.  "passwd" can be either a
	cleartext password or a SHA-1 encrypted password; use the
	included Perl script "sha1pass" to encrypt passwords.
	(Obviously, if you don't encrypt your passwords they will not
	be very secure at all.)

	If you are using passwords, you want to make sure you also use
	the settings "NOESCAPE 1", "PROMPT 0", and either set
	"ALLOWOPTIONS 0" or use a master password (see below.)

	If passwd is an empty string, this menu entry can only be
	unlocked with the master password.


MENU MASTER PASSWD passwd

	Sets a master password.  This password can be used to boot any
	menu entry, and is required for the [Tab] and [Esc] keys to
	work.

Normally, the user can press [Tab] to edit the menu entry, and [Esc]
to return to the SYSLINUX command line.  However, if the configuration
file specifies ALLOWOPTIONS 0, these keys will be disabled, and if
MENU MASTER PASSWD is set, they require the master password.

--------

Another idea:

Use "MAC adresses filtering". You can configure your DHCP server to
give the "filename" and "next-server" arguments only to
known NICs?


Menu with passwords, and "MAC address filtering" would be quite
secure? No?



Regards
Harald Jens?s



-----Original Message-----
From: syslinux-bounces at zytor.com [mailto:syslinux-bounces at zytor.com] On
Behalf Of Jason Keltz
Sent: den 19 december 2005 22:32
To: Murali Krishnan Ganapathy
Cc: syslinux at zytor.com
Subject: Re: [syslinux] problem with PXElinux and security of local LAN

Hi Murali,
I like the challenge response idea a lot, but even the other idea is good..  I
just don't know how to implement either :(

jas.

Murali Krishnan Ganapathy wrote:
> Any kind of security protocol, will require some exchange of 
> information between the local client and the purported DHCP server, 
> which can be verified by both parties. Since this verification needs 
> to be done prior to booting into a kernel, you will have use COMBOOT 
> like stuff to implement the verification.
> 
> More detail of what I had in mind
> 
> (1) Local machine boots into SYSLINUX and runs COMBOOT code stored on 
> local machine
> (2) Local machine asks for DHCP server
> (3) Server S responds
> (4) Local machine asks S for the value of string X (can be implemented 
> as an option-string in DHCP configuration)
> (5) Local machine encrypts "MAGIC STRING" with key Current Date
and
> checks if it equals string X
> (6) If so, trust S and PXE boot from S (using the DHCP server S -- 
> identified by its MAC Address say)
> 
> Yes. Implementing something like this would require a cron job on the 
> server which changes the value of X on a daily basis (or more 
> frequently if you are more paranoid). If this is not done, the bad guy 
> can just intercept the value of X sent by the DHCP server to a client 
> and then mimic the behavior of the DHCP server in the future without 
> knowing the "MAGIC STRING".
> 
> Alternatively, if you dont like the idea of changing the configuration 
> on a regular basis, you should change the protocol to a challenge 
> response protocol, i.e. the local client generates and sends a string 
> to the server which then encrypts it using the MAGIC STRING as key and 
> sends back the result. But this cannot be acheived within the DHCP 
> framework, so the COMBOOT code will be a lot more complicated.
> 
> I guess the question you need to ask is if you want to secure your 
> setup against a casual bad guy or a person determined to hack into 
> your system. If it is the latter, you will need to implement more 
> robust measures, which unfortunately would require more complex work.
> 
> - Murali
> 
> Jason Keltz wrote:
> 
>> That solution sounds interesting albeit a bit complex for me to 
>> implement.   I'm not sure that I quite understand 3.  If the
comboot
>> code asks for a DHCP value, and that value is sent across the wire 
>> encrypted, that seems to require adjusting that code on the DHCP 
>> configuration on a regular basis as well...  further, I also wonder 
>> if it would be possible for a machine to insert itself between step 3 
>> and 4... but definately food for thought.
>>
>> Jason.
>>
>> Murali Krishnan Ganapathy wrote:
>>
>>> Here is an ideal solution. I dont know how much of this is really 
>>> possible.
>>>
>>> (1) Set your BIOS to boot from the local hard disk.
>>> (2) Use SYSLINUX as your boot loader and run a COMBOOT code (stored
>>> in your hard disk)
>>> (3) The COMBOOT Code figures out Who the DHCP server it is talking 
>>> to, and has some kind of check.
>>> (4) If check works out, then chain boot your PXE ROM
>>>
>>> First this is essentially security by obscurity, i.e. in step (3),
I
>>> am assuming that the DHCP server sends an additional string X 
>>> (actually COMBOOT code asks the DHCP server for X). There is some 
>>> magic string hard wired into the COMBOOT code, which gets encrypted
>>> using the current date as the key. If the encrypted string is X
then
>>> you can trust the DHCP server.
>>> If the bad guy finds out the magic string (which is never sent over
>>> the network), then there is no security left.
>>>
>>> It would be cool if this can be implemented. One real life
situation
>>> where SYSLINUX on HDD beats other boot loaders.
>>>
>>> - Murali
>>>
>>> Jason Keltz wrote:
>>>
>>>> Hi.
>>>>
>>>> I want to use PXELinux to build a dynamic boot menu for a
computer
>>>> lab.  Sometimes, the machines need to be in Linux mode/Windows 
>>>> mode/allow the option of Linux/Windows.  I configured this all
fine
>>>> with PXELinux.  My problem is really one of security.  Someone
can
>>>> plug in a laptop with a DHCP server, and tftp server and fake a
lab
>>>> machine to boot into any mode they desire, or even worse, they 
>>>> could configure the local machine to boot Linux in single user 
>>>> mode, and hence allow access to root, local ssh keys, etc.  I
can't
>>>> really think of any easy way how to solve this problem since
there
>>>> is no way to authenticate the PXELinux instance that is loading
or the
>>>> configuration files.   Any ideas?  A locally configured grub
could
>>>> do the same thing, of course, but using pxelinux, I can change
the
>>>> configuration of machines that are off so that when they come
back
>>>> on, they are in the mode that I desire.
>>>>
>>>> :(
>>>>
>>>> Jason.
>>>>
>>>> _______________________________________________
>>>> SYSLINUX mailing list
>>>> Submissions to SYSLINUX at zytor.com
>>>> Unsubscribe or set options at:
>>>> http://www.zytor.com/mailman/listinfo/syslinux
>>>> Please do not send private replies to mailing list traffic.
>>>>
>>>>
>>>
>>
>>
> 
_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX at zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

Hi Murali,

I don't mind if I ALWAYS boot the machine a second time, but there is a
minor chicken and egg problem that I would need to solve.  I can't trust
the state that is stored on the machine if the machine has been off for
a while.  I also need to be able to set the state globally globally set
the saI would always need to probe for the state the first time, and
then reboot into the required O/S.  I don't mind that the partitions,
etc. are fixed since the operating systems stay on the machine anyway.

I still don't know how to load the comboot code, and if that code
requires being installed in a FAT16 partition, how do I protect it from
Windows?

I wonder if there is an even easier solution... somehow I have 3 O/S ..
Windows,Linux, Mini-Linux as you say ... you always boot to Mini-Linux
which probes the web daemon for the state of the machine... at this
point, if I could just boot to linux/windows knowing that the next time
the machine boots, it would still go back to mini-linux, this would be
great!!

jas.

Murali Krishnan Ganapathy wrote:
> Yet another approach. This does not use PXELINUX! Install the Windows 
> and Linux images on two partitions of your hard disk (so with this 
> solution changing the boot image will not be very easy). But it requires 
> two boots everytime instead of one.
> 
> The boot cycle is as follows
> 
> (1) Machine boots locally into COMBOOT code
> (2) Code checks local machine for boot instructions.
> (3) If instructions not found it boots a small linux image
> (4)     small linux goes online and finds out what the state of this 
> machine should be (Windows only/Linux Only/Boot Menu)
> (5)     Stores this information somewhere on the hard disk and reboots 
> so that COMBOOT code can find this info during next boot
> (6) If instructions found, it follows instructions and acts accordingly.
> 
> This requires the local machine to have a Windows installation and a 
> Linux installation which the users can use, and another small linux + 
> initrd.
> As soon as you boot into the small linux, you go online (in one of the 
> init scripts) somewhere you trust (local webserver perhaps) and download 
> a small file which says what the next boot image should be 
> (LINUX/WINDOWS/MENU). The script then writes this information on sector 
> N of the local hard disk (which is not used for any other thing). The 
> COMBOOT code checks sector 6 for this information and when found boots 
> into the appropriate image directly.
> 
> Good Things:
> (a) Uses things which already exist, i.e. linux code to write this info 
> to sector N and COMBOOT code to read this info already exist. (see 
> http://gui.mahamurali.net and click on Autobooting)
> (b) No PXELINUX. No TFTP server, so bad guy cannot give you a kernel to 
> boot from
> (c) A change in your local webserver, will affect all clients the next 
> time they boot. Infact if your logic of (Windows/Linux/Boot Menu) is 
> simple, this logic can be put as a cgi script on your webserver. So you 
> dont need to change anything in the webserver at all!!!
> 
> Bad Things:
>  (a) You need to an extra reboot everytime you boot
>  (b) If you need to change the boot image, you need to change it on 
> every machine
>       or setup another image you can boot into on the local machine 
> (which requires a password) and use that image to help automate the 
> change of boot image.
> 
> Good/Bad:
>   (a) Machine retains state between reboots, (i.e. local files on machine)
> 
> - Murali
> 
> Jason Keltz wrote:
> 
>> I have two new thoughts on solving this problem, but I'm not sure 
>> whether either is doable with PXELinux/syslinux..
>>
>> 1) I've been doing some web searching.  It seems like Intel has a
BIS
>> (Boot Integrity Service) spec that is included in the PXE 2.0 spec.  
>> The code, I believe, is open source - 
>> http://sourceforge.net/projects/bis.
>> I don't see anything in the PXELinux code about handling BIS.  If 
>> PXELinux could handle BIS, it seems like this would completely solve 
>> my problem.  I could authenticate the code that the PXE server 
>> receives! (On the other hand, it's not clear if I could
authenticate
>> the configuration file, but I guess that would only make sense).  If 
>> PXELinux could handle BIS, it seems like it work in a lot of 
>> situations (like mine) where people have recommended not using PXE.  
>> Maybe Peter can comment on the feasibility of adding this 
>> functionality to a future PXElinux?
>>
>> 2) It is "possible" that I could do what I want to do now
with
>> syslinux in a different way.  The question is, is it possible for 
>> syslinux to probe a DHCP server for a value and then to act based on 
>> that value?  I don't see anything about DHCP in the syslinux page,
and
>> the network code may not even be available to syslinux.  This is a bit 
>> like the idea that Murali had.  Our machines are supposed to boot 
>> either directly into linux, directly into Windows, or present a boot 
>> menu.  Before, I was handling the configuration file change on the 
>> server and using PXELinux.  By changing the symlink to the 
>> configuration file, I could change the options available to the 
>> users.  Basically, my idea is this -- syslinux probes the DHCP server 
>> for an option that determines how it proceeds. It might be something 
>> like:
>> value of 1 indicates boot directly to linux
>> value of 2 indicates boot directly to windows
>> value of 3 indicates to present a boot menu.
>> syslinux would then either boot directly to linux/windows/present a 
>> menu.  There are a couple of problems with this:
>>   1) (again) I'm not sure I can probe a DHCP server in syslinux,
>>   2) I'm not sure a syslinux configuration file could act based on
the
>> condition received in 1.
>>   3) In order to install syslinux on the hard disk, it needs to be 
>> installed into a FAT16 partition.  However, by doing this, as far as I 
>> understand it, there would be no security on the FAT16 partition when 
>> users boot Windows XP, and hence users could mess with or disable the 
>> syslinux configuration.
>>
>> If someone might be able to help me with 2, that would be great.
>> If option 1 is magically available and hiding from my sight, it would 
>> be great if someone could help me figure out how to use it..
>>
>> Thanks a bunch..
>>
>> Jas.
>>
>> _______________________________________________
>> SYSLINUX mailing list
>> Submissions to SYSLINUX at zytor.com
>> Unsubscribe or set options at:
>> http://www.zytor.com/mailman/listinfo/syslinux
>> Please do not send private replies to mailing list traffic.
>>
>>
>