Security News
Research
Data Theft Repackaged: A Case Study in Malicious Wrapper Packages on npm
The Socket Research Team breaks down a malicious wrapper package that uses obfuscation to harvest credentials and exfiltrate sensitive data.
The raison d'être of this project can be pretty much described in one single table:
Warming up --------------------------------------
Postgres 1.000 i/100ms
Redis 1.000 i/100ms
Jedis 1.000 i/100ms
Ruby hash 5.000 i/100ms
Calculating -------------------------------------
Postgres 2.289 (± 0.0%) i/s - 12.000 in 5.248779s
Redis 0.016 (± 0.0%) i/s - 1.000 in 60.470617s
Jedis 0.047 (± 0.0%) i/s - 1.000 in 21.109477s
Ruby hash 52.735 (±13.3%) i/s - 260.000 in 5.042344s
It looks slightly odd, but let's explain it a bit.
This is the result of a plain benchmark done on a Mac OS X development machine using JRuby 9.2.0.0 and several libraries:
Postgres
rowRedis
rowJedis
row the jedis_rb gem was used, which is a simple wrapper over the jedis Java libraryMemory
meant using a plain Ruby hashFor the test, a table was created in a Postgres database that looked like a key-value store, something along the lines of:
SQL
CREATE TABLE IF NOT EXISTS things (
k text,
v text,
PRIMARY KEY (k)
);
TRUNCATE TABLE things;
SQL
The SQL query used:
SELECT v FROM things WHERE k='#{random_key}';
The Redis query used:
redis.get(random_key)
Redis should be faster, especially when used as a key-value store, but Postgres actually blew it out of the water in this little test, which seemed odd.
First, let's talk about the elephant in the room, in this case the significant amount of time required by redis-rb: it's a plain Ruby application and a lot of time is spent in userland (280 seconds out of the 298 seconds), while the other libraries use faster languages (Java bindings for both the JDBC driver and Jedis and JRuby optimizes the hash quite nicely).
So, in this case, the language was the bottleneck and maybe some gains can be achieved if the JRuby team will look into the redis-rb gem and suggest some optimizations.
However, it's not so obvious why jedis_rb was so slow compared to Sequel + jdbc-postgres, especially since it's relying on the pretty fast jedis Java library (which is also one of the recommended libraries by Redis).
In this case, the answer lies in the smaller real
time than the total
time, which probably means that there are things happening in parallel. So the answer is probably in the connection pool.
There are two things you can do with a connection pool:
The Sequel gem was doing both, while jedis_rb didn't even an option to set the number of concurrent connections. Actually, when digging a bit through Sequel but also through jedis, it becomes rather obvious that the Sequel developers spent a lot of time and effort to maximize the output of the library by using as many of the connections in the connection pool as possible.
This is where HAJ comes in.
The goal of this project is to have a more advanced connection pool for Jedis which can take advantage of multiple parallel connections to Redis and dramatically increase the output.
Obviously, this is a work in progress so please don't use it in production.
FAQs
Unknown package
We found that haj demonstrated a not healthy version release cadence and project activity because the last version was released a year ago. It has 1 open source maintainer collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
Research
The Socket Research Team breaks down a malicious wrapper package that uses obfuscation to harvest credentials and exfiltrate sensitive data.
Research
Security News
Attackers used a malicious npm package typosquatting a popular ESLint plugin to steal sensitive data, execute commands, and exploit developer systems.
Security News
The Ultralytics' PyPI Package was compromised four times in one weekend through GitHub Actions cache poisoning and failure to rotate previously compromised API tokens.