[syslinux] problem with PXElinux and security of local LAN

Jason Keltz jas at cs.yorku.ca
Tue Dec 20 06:05:39 PST 2005


Hi Harald,

Unfortunately, passwords won't solve the problem.  The problem is that 
someone could insert their own DHCP server and send a rogue pxelinux.0 
down with a rogue configuration that would allow them to do anything on 
the machine.  They could do things like mount a CDROM, boot to single 
user, and mess with Linux, or much worse.

Jason.

Harald_Jensas at Dell.com wrote:
> 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.
> 




More information about the Syslinux mailing list