Extensions dying after query that changes privileges

[ostrowr]

Whenever I run a query that attempts to drop privileges while I have extensions registered, the extensions die.

This output below is from a machine running Amazon Linux release 2 (Karoo), but I've run into the same problem on an Ubuntu machine. I haven't been able to reproduce on OSX and haven't yet tried on Windows.

Building and running the example extension from https://github.com/kolide/osquery-go/blob/master/examples/table/main.go , I get the following output:

osquery> select * from example_table;
+-------------+---------+-------------+---------+
| text        | integer | big_int     | double  |
+-------------+---------+-------------+---------+
| hello world | 123     | -1234567890 | 3.14159 |
+-------------+---------+-------------+---------+
osquery> select * from authorized_keys where uid in (select uid from users);
Thrift: Fri Dec 14 01:58:37 2018 TSocket::read() THRIFT_POLL() Interrupted system call
Thrift: Fri Dec 14 01:58:37 2018 TConnectedClient died: Unknown: Interrupted system call
<.....................QUERY RESULTS...................>
osquery> Thrift: Fri Dec 14 01:58:41 2018 TSocket::open() connect() <Host:  Port: 0>Connection refused
I1214 01:58:41.973999 32340 extensions.cpp:305] Extension UUID 18021 has gone away

osquery> select * from example_table;
Error: no such table: example_table
osquery> 

OSQuery version: Reproduced on both 3.3.0 (downloaded from the website) and built from source at hash 5188ce5288abe0e323b8e8bd364f452134a62d00
osquery-go version: current master (7486f08)

If you configure the extensions to re-register, this is fine as it doesn't actually prevent the query from running, but it means that it's also impossible to successfully execute a query from inside an extension.

I think this is related to osquery/osquery#1638.

I spoke to @groob briefly in slack. I'm not sure if this is an osquery-go issue or an issue with osquery, as I haven't yet tried building a C++ extension. Thanks so much for your help!

[ostrowr]

This is "fixed" by skipping the privilege-dropping logic (i.e. patching osquery with the following)

diff --git a/osquery/core/system.cpp b/osquery/core/system.cpp
index 12b931f..0aa2520 100644
--- a/osquery/core/system.cpp
+++ b/osquery/core/system.cpp
@@ -509,7 +509,7 @@ bool DropPrivileges::dropTo(const std::string& uid, const std::string& gid) {
 }
 
 bool DropPrivileges::dropTo(uid_t uid, gid_t gid) {
-  if (uid == geteuid() && gid == getegid()) {
+  if (1) {
     // Privileges do not need to be dropped.
     return true;
   } else if (dropped() && uid == to_user_ && gid == to_group_) {

Of course, skipping over privilege dropping defeats the whole purpose of, well, privilege dropping.

[zwass]

My instinct is that this is an issue on the osquery end. If you have the time, could you try the equivalent in https://github.com/osquery/osquery-python?

[ostrowr]

Yup, broken there as well. Coincidentally, someone just opened an identical issue in osquery (linked above.) I'll update that issue with what I've discovered here; closing in this repo.