• An analysis of TCP secure SN generation in Linux and its privacy issues
• Tirdad kernel module for random ISN generation

An alternative proposal for editing ISNs without involving the kernel:

In T543#18086, @HulaHoop wrote:

@Patrick What is the status of integration?

@Patrick What is the status of integration? Since we have kloak this is also a great defense to have. There is a script on there for packing as a deb:

In theory, we could make sdwdate provide a local (default) (or optional opt-in server) NTP compatible time provider. Could be useful anyhow. -> sdwdate-server No idea how hard that would be.

And then configure NTP to connect only to that local NTP server.

/usr/sbin/ntpdate as far as I know doesn't accept a command line command to take an offset (or anything). It connects to remote servers in its default design.

Yes, not readily accessible from command line.

The easy way: calculating the offset between local time and the onion average in timesync then using ntpdate's slew option if the offset is less than 0.5s. Otherwise you tell it to step up the time immediately so that you are accurately mimicking the default behavior. However you can force slewing all the time with -B. This way you won't need to touch kernel syscalls as ntpdate should be able to do the operation for you.

From what I understand, this code path is only relevant when timesyncd is talking directly with NTP servers and reacting to replies about deltas between local and remote times. There is no way you can call that function from the command line when using timedatectl standalone AFAICT.

In T815#16509, @HulaHoop wrote:

It doesn't seem that timedatectl supports gradual time adjustment.

Since we are interested in ntpd's default behavior (for blending in purposes) it turns out that it performs instant clock jumps once the delta difference is excessively large otherwise its slewing algorithm would take forever to adjust the time.

It doesn't seem that timedatectl supports gradual time adjustment. Our next best option is ntpd which can do so but cannot coexist with timedatectl - we can only run either but not both. According to popcon, ntpd is the mos widely used time daemon so its the natural choice.

Currently time is set using gnu date (clock jump) (initial run after current boot) or sclockadj (consecutive run) (slow clock adjustment).

the time could be set with timedatectl by feeding it the time with this command:

sclockadj3 is done -> T686.

A miracle has happened. All of https://github.com/yongboy/bindp/pull/6 was merged by upstream.

Very well. So finally they applied our patch.

In T599#12631, @Patrick wrote:

Notified upstream. Let's see if he replies.

bindp pull request - security fixes, debian packaging, and more:
https://github.com/yongboy/bindp/pull/6

What about...?

What about...?

In T599#13705, @Patrick wrote:

Now pushed.

Now pushed.

@Patrick In the master branch the only difference in comparison to the original version that I can see is the main function at the bottom of the file. Did you not apply the changes? This code is still the previous one.

Merged into master.

Please create a new ticket for porting to some better C function.

adjtimex, as far as I can tell, is for tuning the clock to stay accurate. It's not directly for setting a new time. I assume it's used by ntp to speed up and slow down the clock, with more code that checks on it and stops it when it reaches the right time. Reimplementing this is beyond my skill.

OK. It might strain my limited C knowledge, but I'll give it shot.

Looks like at least NTP and chrony use ntp_adjtime/adjtimex

Where is adjtime being used in existing time sync applications? NTP?
chrony? systemd-timesyncd?

Using adjtime would be a simple matter (of programming), but only has microsecond precision.

A popular existing linux tool.

Do we need precise control? The only requirement (other than working) is that it imitate an existing linux tool.

adjtimex/ntp_adjtime looks quite complex, but also allow precise control on how time should be adjusted. From those two, according to manual page ntp_adjtime is preferred.

In T650#13569, @marmarek wrote:

It would avoid trashing logs with Time has been changed every single second, and possibly other side effects.

I've left you some minor comments here: https://github.com/JasonJAyalaP/sclockadj/commit/e9bf84e3a400f7a8ef01e5f00dcefc013d0a9efe

What about using adjtime() syscall instead of all this? It would avoid trashing logs with Time has been changed every single second, and possibly other side effects.

@marmarek Would you be willing to review the C? It's under 75 total lines.

I've rewritten the whole thing in C. It was a simple matter since we no longer need the random interval algorithm. Patrick prefers that it imitates ntpd instead of trying to hide.

Yes, sclockadj runs as root. Usually sclockadj is functional.

the clock_gettime and clock_settime functions are passing zero as their first parameters and that means CLOCK_REALTIME. Firstly the process needs root privilege to touch real time clock, secondly you need to somehow run it by strace like:

TZ is unset since it's started as a systemd unit file.

The C code itself doesn't have any CPU intensive instruction, if the problem is really what is written as inline C, I suspect the issue is either with

clock_gettime(0, &tps)

or

Can't find what debian package ship debug symbols, there is no -dbg package there: https://packages.debian.org/source/stretch/ruby2.3

Ah, it's ruby... So, python-dbg is irrelevant, but trying gdb may still be a good idea.

Thanks for having a look!

I don't see any loop there and only very simple function calls, so I don't see how that would trigger such bug...

Do you see any things a malicious application could to gain arbitrary code execution through bindp?

Notified upstream. Let's see if he replies.

Functionally speaking, as I tested, it works great in Whonix. Pretty much done.

@Patrick Do you have anything else from this project remained that needs extra working on ?

Works for me!

@Patrick Updated: http://pastebin.com/9XcTZwVG

@Patrick I need more debug info, I suspect the connect function is causing trouble.
Please use this and send the output again: http://pastebin.com/BZqTRBTc

Added that. And added some intent style changes. Please tell me if my C intent style is actually making things non-standard / worse than before.

@Patrick
Code fixed. Please check and use this: http://pastebin.com/GvDpuC0f

In T599#12621, @Patrick wrote:

Why did you add #ifdef SO_REUSEPORT?

Why did you add #ifdef SO_REUSEPORT?

Well the segfault error is strange here, I must run it locally with your setup to check and debug which is not possible for now, but it's good you made it work finally. Good job Patrick. Still I think PIE related options are not needed for libraries.
I will modify the code by tonight and send the new revisions.

It's functional! Successfully changes the listener IP.

Did that.

no segfault:

That's great! Thank you for your help! Just now tested. Unfortunately it does not work.

@Patrick Nice, now regular testing needs to be done from your side, please keep in mind that connect function has to change as well, but before that I must assure that current bind() works properly and as expected. If everything goes well I will write whole code from scratch for you by modifying init and connect functions.

Did that.

@Patrick Add

What does DSO mean?

Can we have all hardening with PIE enabled as well as without ld warning?

In T599#12601, @s.sh wrote:

But these warnings are not related to my revisions, they probably existed in original code.

@Patrick You can compile without -fPIE (I think -fPIC is enough):

In T599#12599, @s.sh wrote:

@Patrick Add

#include <arpa/inet.h>

at the beginning of the file.

@Patrick Add

#include <arpa/inet.h>

Do you know how to fix these compiler warning?

one more stylistic fix:

@Patrick The reason that I inserted curly braces is that the first line after "case AF_INET:" is not syntactically a statement, to work around this you may use a dummy sentence or use braces like what I did. The break keyword can be inside that block; there is no difference.

I created a branch address-family-check to ease review.

@marmarek I changed bind function and uploaded the code at: http://pastebin.com/dZb4yedz

@marmarek If the problem is only with applications listening on both AF_INET and AF_UNIX,

@marmarek If the problem is only with applications listening on both AF_INET and AF_UNIX, I think the solution should be easy, we can change the bind function in a way that it only changes local address of the sockaddr_storage while the protocol family is AF_INET. For AF_UNIX address family there doesn't seem to be any need to change the address (the pathname of the socket). By applying these changes will the problem get solved? If yes, I will rewrite the bind function for you to test.

The problem is not in connect function, but in bind. It assume AF_INET family, casting sk pointer to struct sockaddr_in. But if socket family is something different, the structure also may be different (for example struct sockaddr_un for AF_UNIX). In practice, besides misusing this library, the problem only applies to applications listening on both locak (AF_UNIX) and network (AF_INET) sockets. Because you don't use this library for AF_UNIX-only applications.