Document the (in)security features of CTM, especially ctm_rmail.
This commit is contained in:
parent
fac8edac5e
commit
3aa5f62f03
Notes:
svn2git
2020-12-20 02:59:44 +00:00
svn path=/head/; revision=55796
@ -222,7 +222,33 @@ Pathnames can be selected for CTM's consideration using the
|
||||
option.
|
||||
|
||||
.El
|
||||
|
||||
.Pp
|
||||
.Sh SECURITY
|
||||
.Pp
|
||||
CTM is an
|
||||
.Bf Em
|
||||
INSECURE PROTOCOL
|
||||
.Ef
|
||||
- there is no authentication performed that the
|
||||
changes applied to the source code were sent by a
|
||||
trusted party, and so care should be taken if the
|
||||
CTM deltas are obtained via an unauthenticated
|
||||
medium such as email.
|
||||
It is a relatively simple matter for an attacker
|
||||
to forge a CTM delta to replace or precede the
|
||||
legitimate one and insert malicious code into your
|
||||
source tree.
|
||||
If the legitimate delta is somehow prevented from
|
||||
arriving, this will go unnoticed until a later
|
||||
delta attempts to touch the same file, at which
|
||||
point the MD5 checksum will fail.
|
||||
.Pp
|
||||
A future version of
|
||||
.Fx
|
||||
may solve this problem by authenticating CTM
|
||||
deltas using cryptographic signatures, but in the
|
||||
mean time it is strongly recommended that you
|
||||
obtain the CTM deltas via FTP, and not via email.
|
||||
.Sh ENVIRONMENT
|
||||
.Ev TMPDIR,
|
||||
if set to a pathname, will cause ctm to use that pathname
|
||||
|
@ -364,30 +364,31 @@ to execute
|
||||
.Xr ctm
|
||||
on the (non-FreeBSD) machine that this example was taken from.
|
||||
.Sh SECURITY
|
||||
If you automatically take your mail and pass it to a file tree patcher, you
|
||||
might think you are handing the keys to your system to the crackers! Happily,
|
||||
the window for mischief is quite small.
|
||||
.Nm ctm_rmail
|
||||
is careful to write only to the directories given to it (by not believing any
|
||||
.Dq /
|
||||
characters in the delta name), and the latest
|
||||
.Xr ctm
|
||||
disallows absolute pathnames and
|
||||
.Dq \&\.\.
|
||||
in files it manipulates, so the worst you
|
||||
could lose are a few source tree files (recoverable from your deltas).
|
||||
Since
|
||||
.Xr ctm
|
||||
requires that a
|
||||
.Xr md5
|
||||
checksum match before it touches a file, only fellow
|
||||
source recipients would be able to generate a fake delta, and they're such
|
||||
nice folk that they wouldn't even think of it! :-)
|
||||
.Pp
|
||||
Even this possibility could be removed by using cryptographic signatures.
|
||||
A possible future enhancement would be to use
|
||||
.Nm PGP
|
||||
to provide a secure wrapper.
|
||||
CTM is an
|
||||
.Bf Em
|
||||
INSECURE PROTOCOL
|
||||
.Ef
|
||||
- there is no authentication performed that the
|
||||
changes applied to the source code were sent by a
|
||||
trusted party, and so care should be taken if the
|
||||
CTM deltas are obtained via an unauthenticated
|
||||
medium such as email.
|
||||
It is a relatively simple matter for an attacker
|
||||
to forge a CTM delta to replace or precede the
|
||||
legitimate one and insert malicious code into your
|
||||
source tree.
|
||||
If the legitimate delta is somehow prevented from
|
||||
arriving, this will go unnoticed until a later
|
||||
delta attempts to touch the same file, at which
|
||||
point the MD5 checksum will fail.
|
||||
.Pp
|
||||
A future version of
|
||||
.Fx
|
||||
may solve this problem by authenticating CTM
|
||||
deltas using cryptographic signatures, but in the
|
||||
mean time it is strongly recommended that you
|
||||
obtain the CTM deltas via FTP, and not via email.
|
||||
.\" This next request is for sections 1, 6, 7 & 8 only
|
||||
.Sh ENVIRONMENT
|
||||
If deltas are to be applied then
|
||||
|
Loading…
Reference in New Issue
Block a user