2018-03-01 09:27:46 +08:00
|
|
|
// MmapWriteExecChecker.cpp - Check for the prot argument -----------------===//
|
|
|
|
//
|
2019-01-19 16:50:56 +08:00
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
2018-03-01 09:27:46 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// This checker tests the 3rd argument of mmap's calls to check if
|
|
|
|
// it is writable and executable in the same time. It's somehow
|
|
|
|
// an optional checker since for example in JIT libraries it is pretty common.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
[analyzer][NFC] Move CheckerRegistry from the Core directory to Frontend
ClangCheckerRegistry is a very non-obvious, poorly documented, weird concept.
It derives from CheckerRegistry, and is placed in lib/StaticAnalyzer/Frontend,
whereas it's base is located in lib/StaticAnalyzer/Core. It was, from what I can
imagine, used to circumvent the problem that the registry functions of the
checkers are located in the clangStaticAnalyzerCheckers library, but that
library depends on clangStaticAnalyzerCore. However, clangStaticAnalyzerFrontend
depends on both of those libraries.
One can make the observation however, that CheckerRegistry has no place in Core,
it isn't used there at all! The only place where it is used is Frontend, which
is where it ultimately belongs.
This move implies that since
include/clang/StaticAnalyzer/Checkers/ClangCheckers.h only contained a single function:
class CheckerRegistry;
void registerBuiltinCheckers(CheckerRegistry ®istry);
it had to re purposed, as CheckerRegistry is no longer available to
clangStaticAnalyzerCheckers. It was renamed to BuiltinCheckerRegistration.h,
which actually describes it a lot better -- it does not contain the registration
functions for checkers, but only those generated by the tblgen files.
Differential Revision: https://reviews.llvm.org/D54436
llvm-svn: 349275
2018-12-16 00:23:51 +08:00
|
|
|
#include "clang/StaticAnalyzer/Checkers/BuiltinCheckerRegistration.h"
|
2018-03-01 09:27:46 +08:00
|
|
|
|
|
|
|
#include "clang/StaticAnalyzer/Core/BugReporter/BugType.h"
|
|
|
|
#include "clang/StaticAnalyzer/Core/Checker.h"
|
|
|
|
#include "clang/StaticAnalyzer/Core/CheckerManager.h"
|
|
|
|
#include "clang/StaticAnalyzer/Core/PathSensitive/CallEvent.h"
|
|
|
|
#include "clang/StaticAnalyzer/Core/PathSensitive/CheckerContext.h"
|
|
|
|
|
|
|
|
using namespace clang;
|
|
|
|
using namespace ento;
|
|
|
|
using llvm::APSInt;
|
|
|
|
|
|
|
|
namespace {
|
|
|
|
class MmapWriteExecChecker : public Checker<check::PreCall> {
|
|
|
|
CallDescription MmapFn;
|
2018-03-09 09:47:24 +08:00
|
|
|
CallDescription MprotectFn;
|
2018-03-01 09:27:46 +08:00
|
|
|
static int ProtWrite;
|
|
|
|
static int ProtExec;
|
|
|
|
static int ProtRead;
|
|
|
|
mutable std::unique_ptr<BugType> BT;
|
|
|
|
public:
|
2018-03-09 09:47:24 +08:00
|
|
|
MmapWriteExecChecker() : MmapFn("mmap", 6), MprotectFn("mprotect", 3) {}
|
2018-03-01 09:27:46 +08:00
|
|
|
void checkPreCall(const CallEvent &Call, CheckerContext &C) const;
|
|
|
|
int ProtExecOv;
|
|
|
|
int ProtReadOv;
|
|
|
|
};
|
|
|
|
}
|
|
|
|
|
|
|
|
int MmapWriteExecChecker::ProtWrite = 0x02;
|
|
|
|
int MmapWriteExecChecker::ProtExec = 0x04;
|
|
|
|
int MmapWriteExecChecker::ProtRead = 0x01;
|
|
|
|
|
|
|
|
void MmapWriteExecChecker::checkPreCall(const CallEvent &Call,
|
|
|
|
CheckerContext &C) const {
|
2018-03-09 09:47:24 +08:00
|
|
|
if (Call.isCalled(MmapFn) || Call.isCalled(MprotectFn)) {
|
|
|
|
SVal ProtVal = Call.getArgSVal(2);
|
2018-03-01 09:27:46 +08:00
|
|
|
Optional<nonloc::ConcreteInt> ProtLoc = ProtVal.getAs<nonloc::ConcreteInt>();
|
|
|
|
int64_t Prot = ProtLoc->getValue().getSExtValue();
|
|
|
|
if (ProtExecOv != ProtExec)
|
|
|
|
ProtExec = ProtExecOv;
|
|
|
|
if (ProtReadOv != ProtRead)
|
|
|
|
ProtRead = ProtReadOv;
|
|
|
|
|
|
|
|
// Wrong settings
|
|
|
|
if (ProtRead == ProtExec)
|
|
|
|
return;
|
|
|
|
|
|
|
|
if ((Prot & (ProtWrite | ProtExec)) == (ProtWrite | ProtExec)) {
|
|
|
|
if (!BT)
|
|
|
|
BT.reset(new BugType(this, "W^X check fails, Write Exec prot flags set", "Security"));
|
|
|
|
|
|
|
|
ExplodedNode *N = C.generateNonFatalErrorNode();
|
|
|
|
if (!N)
|
|
|
|
return;
|
|
|
|
|
2019-09-10 04:34:40 +08:00
|
|
|
auto Report = std::make_unique<PathSensitiveBugReport>(
|
2018-03-01 09:27:46 +08:00
|
|
|
*BT, "Both PROT_WRITE and PROT_EXEC flags are set. This can "
|
|
|
|
"lead to exploitable memory regions, which could be overwritten "
|
|
|
|
"with malicious code", N);
|
|
|
|
Report->addRange(Call.getArgSourceRange(2));
|
|
|
|
C.emitReport(std::move(Report));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void ento::registerMmapWriteExecChecker(CheckerManager &mgr) {
|
|
|
|
MmapWriteExecChecker *Mwec =
|
|
|
|
mgr.registerChecker<MmapWriteExecChecker>();
|
|
|
|
Mwec->ProtExecOv =
|
[analyzer] Restrict AnalyzerOptions' interface so that non-checker objects have to be registered
One of the reasons why AnalyzerOptions is so chaotic is that options can be
retrieved from the command line whenever and wherever. This allowed for some
options to be forgotten for a looooooong time. Have you ever heard of
"region-store-small-struct-limit"? In order to prevent this in the future, I'm
proposing to restrict AnalyzerOptions' interface so that only checker options
can be retrieved without special getters. I would like to make every option be
accessible only through a getter, but checkers from plugins are a thing, so I'll
have to figure something out for that.
This also forces developers who'd like to add a new option to register it
properly in the .def file.
This is done by
* making the third checker pointer parameter non-optional, and checked by an
assert to be non-null.
* I added new, but private non-checkers option initializers, meant only for
internal use,
* Renamed these methods accordingly (mind the consistent name for once with
getBooleanOption!):
- getOptionAsString -> getCheckerStringOption,
- getOptionAsInteger -> getCheckerIntegerOption
* The 3 functions meant for initializing data members (with the not very
descriptive getBooleanOption, getOptionAsString and getOptionAsUInt names)
were renamed to be overloads of the getAndInitOption function name.
* All options were in some way retrieved via getCheckerOption. I removed it, and
moved the logic to getStringOption and getCheckerStringOption. This did cause
some code duplication, but that's the only way I could do it, now that checker
and non-checker options are separated. Note that the non-checker version
inserts the new option to the ConfigTable with the default value, but the
checker version only attempts to find already existing entries. This is how
it always worked, but this is clunky and I might end reworking that too, so we
can eventually get a ConfigTable that contains the entire configuration of the
analyzer.
Differential Revision: https://reviews.llvm.org/D53483
llvm-svn: 346113
2018-11-05 11:50:37 +08:00
|
|
|
mgr.getAnalyzerOptions()
|
[analyzer] Remove the default value arg from getChecker*Option
Since D57922, the config table contains every checker option, and it's default
value, so having it as an argument for getChecker*Option is redundant.
By the time any of the getChecker*Option function is called, we verified the
value in CheckerRegistry (after D57860), so we can confidently assert here, as
any irregularities detected at this point must be a programmer error. However,
in compatibility mode, verification won't happen, so the default value must be
restored.
This implies something else, other than adding removing one more potential point
of failure -- debug.ConfigDumper will always contain valid values for
checker/package options!
Differential Revision: https://reviews.llvm.org/D59195
llvm-svn: 361042
2019-05-17 23:52:13 +08:00
|
|
|
.getCheckerIntegerOption(Mwec, "MmapProtExec");
|
2018-03-01 09:27:46 +08:00
|
|
|
Mwec->ProtReadOv =
|
[analyzer] Restrict AnalyzerOptions' interface so that non-checker objects have to be registered
One of the reasons why AnalyzerOptions is so chaotic is that options can be
retrieved from the command line whenever and wherever. This allowed for some
options to be forgotten for a looooooong time. Have you ever heard of
"region-store-small-struct-limit"? In order to prevent this in the future, I'm
proposing to restrict AnalyzerOptions' interface so that only checker options
can be retrieved without special getters. I would like to make every option be
accessible only through a getter, but checkers from plugins are a thing, so I'll
have to figure something out for that.
This also forces developers who'd like to add a new option to register it
properly in the .def file.
This is done by
* making the third checker pointer parameter non-optional, and checked by an
assert to be non-null.
* I added new, but private non-checkers option initializers, meant only for
internal use,
* Renamed these methods accordingly (mind the consistent name for once with
getBooleanOption!):
- getOptionAsString -> getCheckerStringOption,
- getOptionAsInteger -> getCheckerIntegerOption
* The 3 functions meant for initializing data members (with the not very
descriptive getBooleanOption, getOptionAsString and getOptionAsUInt names)
were renamed to be overloads of the getAndInitOption function name.
* All options were in some way retrieved via getCheckerOption. I removed it, and
moved the logic to getStringOption and getCheckerStringOption. This did cause
some code duplication, but that's the only way I could do it, now that checker
and non-checker options are separated. Note that the non-checker version
inserts the new option to the ConfigTable with the default value, but the
checker version only attempts to find already existing entries. This is how
it always worked, but this is clunky and I might end reworking that too, so we
can eventually get a ConfigTable that contains the entire configuration of the
analyzer.
Differential Revision: https://reviews.llvm.org/D53483
llvm-svn: 346113
2018-11-05 11:50:37 +08:00
|
|
|
mgr.getAnalyzerOptions()
|
[analyzer] Remove the default value arg from getChecker*Option
Since D57922, the config table contains every checker option, and it's default
value, so having it as an argument for getChecker*Option is redundant.
By the time any of the getChecker*Option function is called, we verified the
value in CheckerRegistry (after D57860), so we can confidently assert here, as
any irregularities detected at this point must be a programmer error. However,
in compatibility mode, verification won't happen, so the default value must be
restored.
This implies something else, other than adding removing one more potential point
of failure -- debug.ConfigDumper will always contain valid values for
checker/package options!
Differential Revision: https://reviews.llvm.org/D59195
llvm-svn: 361042
2019-05-17 23:52:13 +08:00
|
|
|
.getCheckerIntegerOption(Mwec, "MmapProtRead");
|
2018-03-01 09:27:46 +08:00
|
|
|
}
|
2019-01-26 22:23:08 +08:00
|
|
|
|
2020-03-27 21:29:31 +08:00
|
|
|
bool ento::shouldRegisterMmapWriteExecChecker(const CheckerManager &mgr) {
|
2019-01-26 22:23:08 +08:00
|
|
|
return true;
|
|
|
|
}
|