All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joseph Reynolds <jrey@linux.ibm.com>
To: Adriana Kobylak <anoo@linux.ibm.com>,
	Gunnar Mills <gmills@linux.vnet.ibm.com>
Cc: openbmc@lists.ozlabs.org, rgrs <rgrs@protonmail.com>, anoo@us.ibm.com
Subject: Re: BMC update via TFTP
Date: Wed, 4 Dec 2019 09:47:10 -0600	[thread overview]
Message-ID: <ed917fd0-61e1-3ff8-05f9-863d3e451c93@linux.ibm.com> (raw)
In-Reply-To: <9e0303e5beb34b9bb50b050cd56e35d8@linux.vnet.ibm.com>

On 12/3/19 1:55 PM, Adriana Kobylak wrote:
> On 2019-12-03 11:08, Gunnar Mills wrote:
>> On 12/3/2019 10:12 AM, Gunnar Mills wrote:
>>
>>>> In BMC WebUI under "Download image file from TFTP server" section,
>>>>
>>>> we have text fields "TFTP Server IP address" and "File name".
>>>> "File name" doesn't take folders in path. Is this a bug or
>>>> expected behavior?
>>>>
>>>> TFTP downloads work only if file is kept in root of tftp share.
>>> This is expected.
>>>
>> https://github.com/openbmc/phosphor-bmc-code-mgmt/blob/b0ce996ac60cf80487d71c3cdb7165d065079377/download_manager.cpp#L33 
>>
>>> [1]
>>
>> As long as we continue to sanitize the local filename, I don't see why
>> we need to limit the source file name.
>>  Patrick, Adriana, Any objection? Remember why we wrote it this way? I
>> assume for simplicity..?
>
> It was done for security to prevent users from specifying a file 
> outside the tftp directory, such as /mydir/../root/system-file.
> But seems the current file name handling breaks the ability to get 
> files from a subdir like Raj pointed out, we should be able to fix 
> that out, tftp supports having a file in subdirs such as 
> /tftpboot/subdirectory/file, and passing /subdirectory/file to it as 
> the path.

It seems to me that the burden must be on the TFTP server to protect 
itself.  See the "Security Considerations" section of RFC 1350 - 
https://tools.ietf.org/html/rfc1350
Specifically, OpenBMC only needs read access (it does not need to write 
files to the TFTP server) and only needs to be able to access files the 
TFTP server intends to provide (typically: all the files under a 
specific directory).

To be more clear:
- OpenBMC does not provide a TFTP server, so this is guidance for 
someone setting a TFTP server for use with an OpenBMC system
- The TFTP server only needs to offer READ access.
- The TFTP server ought to prevent clients from using 
cleverly-constructed pathnames (for example, any file which begins with 
"/" or contains an ".." element) to access files outside of its sandbox.
- That said, I am not a TFTP expert, and whichever TFTP server is used, 
its security guidance should be followed.

What all of the above, I think it would be okay for OpenBMC to validate 
the pathname it sends to the TFTP server, but don't think it is necessary.

Finally, I hope we can move away from TFTP and more toward a secure 
image distribution approach.
Note that TFTP is disabled in OpenBMC by default.  See 
https://github.com/openbmc/bmcweb/blob/master/CMakeLists.txt

- Joseph

>>
>>  Thanks,
>>  Gunnar
>>
>>
>> Links:
>> ------
>> [1]
>> https://github.com/openbmc/phosphor-bmc-code-mgmt/blob/b0ce996ac60cf80487d71c3cdb7165d065079377/download_manager.cpp#L33 
>>

  reply	other threads:[~2019-12-04 15:47 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-03 12:02 BMC update via TFTP rgrs
2019-12-03 16:12 ` Gunnar Mills
2019-12-03 17:08   ` Gunnar Mills
2019-12-03 19:55     ` Adriana Kobylak
2019-12-04 15:47       ` Joseph Reynolds [this message]
2019-12-04 21:36         ` Vernon Mauery
2019-12-05 11:05           ` Alexander Tereschenko
2019-12-05 22:37             ` Vernon Mauery
2019-12-06 14:03               ` Alexander Tereschenko
2019-12-06 22:52                 ` Joseph Reynolds
2019-12-09 16:06                   ` Alexander Tereschenko
2019-12-10  1:25                     ` Joseph Reynolds
2019-12-10 18:58                       ` [EXTERNAL] " Neeraj Ladkani
2019-12-10 21:10                         ` Joseph Reynolds
2019-12-11  4:56                           ` Bonnie Lo/WYHQ/Wiwynn
2019-12-11  5:59                             ` Lei YU
2019-12-11 21:51                           ` Milton Miller II
2019-12-11 11:02                       ` Alexander Tereschenko
2019-12-11 20:17                         ` Joseph Reynolds

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ed917fd0-61e1-3ff8-05f9-863d3e451c93@linux.ibm.com \
    --to=jrey@linux.ibm.com \
    --cc=anoo@linux.ibm.com \
    --cc=anoo@us.ibm.com \
    --cc=gmills@linux.vnet.ibm.com \
    --cc=openbmc@lists.ozlabs.org \
    --cc=rgrs@protonmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.