| ca2d3691 | 22-Jul-2018 |
Alan Somers <[email protected]> |
Fix several Coverity warnings in tftp
Some of the changes are in the libexec/tftpd directory, but to functions that
are only used by tftp(1) (they share some code).
* strcpy => strlcpy (1006793, 10
Fix several Coverity warnings in tftp
Some of the changes are in the libexec/tftpd directory, but to functions that
are only used by tftp(1) (they share some code).
* strcpy => strlcpy (1006793, 1006794, 1006796, 1006741)
* Unchecked return value and TOCTTOU (1009314)
* NULL pointer dereference (1018035, 1018036)
Reported by: Coverity
CID: 1006793, 1006794, 1006796, 1006741, 1009314, 1018035
CID: 1018036
MFC after: 2 weeks
show more ...
|
| 6301d647 | 10-Mar-2018 |
Alan Somers <[email protected]> |
tftpd: reject unknown opcodes
If tftpd receives a command with an unknown opcode, it simply exits 1. It
doesn't send an ERROR packet, and the client will hang waiting for one. Fix
it.
PR: 226005
tftpd: reject unknown opcodes
If tftpd receives a command with an unknown opcode, it simply exits 1. It
doesn't send an ERROR packet, and the client will hang waiting for one. Fix
it.
PR: 226005
MFC after: 3 weeks
show more ...
|
| b7da179e | 10-Mar-2018 |
Alan Somers <[email protected]> |
tftpd: Abort on an WRQ access violation
On a WRQ (write request) tftpd checks whether the client has access
permission for the file in question. If not, then the write is prevented.
However, tftpd
tftpd: Abort on an WRQ access violation
On a WRQ (write request) tftpd checks whether the client has access
permission for the file in question. If not, then the write is prevented.
However, tftpd doesn't reply with an ERROR packet, nor does it abort.
Instead, it tries to receive the packet anyway.
The symptom is slightly different depending on the nature of the error. If
the target file is nonexistent and tftpd lacks permission to create it, then
tftpd will willingly receive the file, but not write it anywhere. If the
file exists but is not writable, then tftpd will fail to ACK to WRQ.
PR: 225996
MFC after: 3 weeks
show more ...
|
| d89aca76 | 10-Mar-2018 |
Alan Somers <[email protected]> |
tftpd: Verify world-writability for WRQ when using relative paths
tftpd(8) says that files may only be written if they already exist and are
publicly writable. tftpd.c verifies that a file is publi
tftpd: Verify world-writability for WRQ when using relative paths
tftpd(8) says that files may only be written if they already exist and are
publicly writable. tftpd.c verifies that a file is publicly writable if it
uses an absolute pathname. However, if the pathname is relative, that check
is skipped. Fix it.
Note that this is not a security vulnerability, because the transfer
ultimately doesn't work unless the file already exists and is owned by user
nobody. Also, this bug does not affect the default configuration, because
the default uses the "-s" option which makes all pathnames absolute.
PR: 226004
MFC after: 3 weeks
show more ...
|
| d3953c1f | 09-Mar-2018 |
Alan Somers <[email protected]> |
tftpd: Flush files as soon as they are fully received
On an RRQ, tftpd doesn't exit as soon as it's finished receiving a file.
Instead, it waits five seconds just in case the client didn't receive t
tftpd: Flush files as soon as they are fully received
On an RRQ, tftpd doesn't exit as soon as it's finished receiving a file.
Instead, it waits five seconds just in case the client didn't receive the
server's last ACK and decides to resend the final DATA packet.
Unfortunately, this created a 5 second delay from when the client thinks
it's done sending the file, and when the file is available for other
processes.
Fix this bug by closing the file as soon as receipt is finished.
PR: 157700
Reported by: Barry Mishler <[email protected]>
MFC after: 3 weeks
show more ...
|