Permalink
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Browse files
Browse the repository at this point in the history
Fix [bad6cc213d]: A format string vulnerability in Tcl nmakehelp.c al…
…lows code execution via a crated file. Also change a memcpy() to a memmove(), because the range could be overlapping
- Loading branch information
4705dbdThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
CVE-2021-35331 was assigned for this issue.
4705dbdThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
jeez! do you really think that a bug in a build helper actually need a CVE entry?
4705dbdThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The CVE has the status DISPUTED now. I share DHR's opinion that - even though it's indeed a bug - it cannot be used for any "code execution", since this file is only a build helper. Fixing it is no work at all (proof: this commit), any discussion about it has no further value for me.
4705dbdThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A discussion (if argumentative) has always a value, Jan...
Just I don't think that someone would be able to illustrate any even a theoretical attack vector by its usage at the moment.
4705dbdThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The argument "only a build helper" does not directly address the danger of code execution. I came here from a CVE alert and I believe the likeliest most impactful attack could involve a build farm machine. The
nmakehlpwas intended as a Windows tool but I guess for the sake of reusability, the same tool may be used on a Linux CI/CD farm machine.nmakehlpis vulnerable.nmakehlpto replace token patterns with secrets from a "substitution file" when building, testing or deploying a project,nmakehlp -s SECRETS_FILE CONFIG_TEMPLATE_FILE > CONFIG_FILEDepending on whether the conditions are possible, the risk of the vulnerability before its fix may vary from zero to critical.
The existing code has another visible vulnerability where the szCopy's running pointer is written to without checking for the buffer overrun on lines 659 and 661,
tcl/win/nmakehlp.c
Lines 645 to 667 in 2192064
4705dbdThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The same is valid if the source code is under your full control (someone can simply change it to make it vulnerable by the next build process).
rm -rf ...and co);it is the matter of (invalid) usage and one cannot blame the tool for that;
Likewise if someone allows to add arbitrary data (without to validate it) as a parameter to the build-scripts, no matter where, it is pretty simple to achieve similar impact by many stable tools (without known "vulnerabilities").
For instance because one could force it to do something unexpected (theoretically even to build some other tool, see P. 1, and then use it hereafter).
Anyway in provided scenario the issue will be rather the usage of unfiltered foreign input for a parameter supplied to nmakehlp. Not the "vulnerability" of the nmakehlp self.
Especially on windows, which has notoriously a vulnerable command processor, so you don't really want to invoke something on windows without parameter validation.
But again, I am not against the "fix" at all, just to explain why calling that a vulnerability and provide a CVE is a bit too heavy for that kind of "tool", well basically build-helper.
However you can provide your fix (patch) to core.tcl-lang.org.
4705dbdThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I remember that POODLE was also limited to attackers having a peculiar relationship with the data they were attacking. Thanks to the intricacy of the web usage patterns established in the past decades, the relationship did make sense. The attacker would need to
(A) have partial write-only access to the plaintext data. This was made possible by getting the victims open a malicious site whose UI would start sending requests to the application server. The attacker would also need to
(B) have read/write access to the encrypted data in transit (possibly by setting up a fake WiFi hotspot).
Despite so many IFs, the vulnerability was considered serious. I agree that nmakehlp's scope of use is billion times smaller than that of TLS. Thanks for providing additional points against the likelihood of the attack (I may disagree about technicalities. The exploit does not require access to command line modifications. It only needs partial write-only access to one of the 2 files via either the source code repository or a build machine's other data flow). I agree often times having partial write access comes with many other permissions and attacks that would make the abuse of nmakehlp unfeasible. These pro et contra arguments help in evaluating the cost/benefit of upgrading/keeping the Tcl version.