- Admin - Freifunk Nordwest

Kühlungsproblem srv19
by Bjoern Franke 28 Dec '18

28 Dec '18

Moin, hat srv19 ggf. ein Kühlungsproblem? https://p.rrbone.net/paste/Xyz0vVzV#ftYmy3IcjxLdjzLt+dLxNVTAI7-d7Swb9xV+8BZ… Grüße

3 5

help
by Robert Köster 19 Dec '18

19 Dec '18

help

1 0

Umstellung IPv6 Oldenburg
by Bjoern Franke 19 Dec '18

19 Dec '18

Moin, wann können wir denn mal die IPv6-Umstellung von Oldenburg in Angriff nehmen? @Stefan: Wie wäre es mit zwischen den Jahren? vg

2 1

Re: [Nordwest] Re: Netflix wird blockiert
by Bjoern Franke 13 Dec '18

13 Dec '18

Moin, > > ja, ist bei HE Tunnelbrokern genau das selbe, da hier massenweise > Anfragen kommen. > > Anfrage an deren NOC ist seit lange Zeit unbeantwortet, da können wir > nichts machten. > > Zukünftig nutze für sowas bitte die Admin ML! > Interessant wäre aber, mit welchen IP-Ranges das Problem auftritt. Ergo: Funktioniert es mit unserem IPv6-Prefix nicht, oder nur mit dem von FFRL nicht, oder nutzte der/die Betreffende nur IPv4? Grüße bjo

2 2

nds meeting
by Martin Berthold 28 Nov '18

28 Nov '18

moin, sorry, wenn ich hier so "reinstürm"... stefan, wir hatten sa kn h. geschnackt... ich hab da mal an paar schrauben gedreht. meld dich mal per pm, bitte danke! martin

2 1

Schönen Tag
by BLEMAIN FINANCE 21 Nov '18

21 Nov '18

Schönen Tag: Mein Name ist Mark Anderson, Direktor einer privaten Darlehensagentur von Blemain Finance Ltd Vereinigtes Königreich. Ich bin hier, um ein Darlehensprogramm vorzustellen, das Ihnen helfen wird, Ihre finanzielle Situation zu verbessern, die Wirtschaft zu verbessern und Sie von der Finanzkrise / dem Finanzproblem zu befreien. Kreditangebot kurz- und langfristig für Kunden mit einer Rate von 3%, asAutokredit, Unternehmensdarlehen usw. Wenn Sie an einem Darlehen von uns über diese E-Mail interessiert sind: blemain_finance(a)webadicta.org Bitte füllen Sie das Anmeldeformular aus: Name:Geschlecht:Land:Benötigte Menge:Länge des Darlehens:Der Grund für den Kredit: Danke für dein Verständnis. Mark Anderson.Schönen Tag: Mein Name ist Mark Anderson, Direktor einer privaten Darlehensagentur von Blemain Finance Ltd Vereinigtes Königreich. Ich bin hier, um ein Darlehensprogramm vorzustellen, das Ihnen helfen wird, Ihre finanzielle Situation zu verbessern, die Wirtschaft zu verbessern und Sie von der Finanzkrise / dem Finanzproblem zu befreien. Kreditangebot kurz- und langfristig für Kunden mit einer Rate von 3%, as Autokredit, Unternehmensdarlehen usw. Wenn Sie an einem Darlehen von uns über diese E-Mail interessiert sind: blemain_finance(a)webadicta.org Bitte füllen Sie das Anmeldeformular aus: Name: Geschlecht: Land: Benötigte Menge: Länge des Darlehens: Der Grund für den Kredit: Danke für dein Verständnis. Mark Anderson.

1 0

Freifunk im Bootshafen
by Rüdiger Haack 18 Nov '18

18 Nov '18

Hallo liebe Community. Ich habe eine Anfrage unseres Vorstandes bekommen. Auf unserem Hafen soll ein Wlan installiert werden, das von Gästen und Mitgliedern genutzt werden kann. Nun haben wir dort noch keinerlei Internetzugang liegen, was sich aber in Kürze ändern soll. Nun geht es um die Einrichtung der Hardware. Das Gelände ist ca. 200 m lang und 30 m breit. Siehe Adresse: "Am Krummen Tief 4, 26632 Ihlow" Ich dachte dort an je einen Router am Anfang und einen am Ende des Hafens und dort jeweils eine der drei Antennen gegen eine Richtantenne zu tauschen. Der eine Router bekommt dann einen Internetanschluss. Wäre die Idee so durchführbar, oder gibt es bessere Lösungen ? Vielleicht gibt es ja bereits irgendwelche Erfahrungen. Mit freundlichen Grüssen Rüdiger Haack

1 0

nordwest@lists.ffnw.de post from wolfgang@ziffels.de requires approval
by nordwest-owner＠lists.ffnw.de 10 Nov '18

10 Nov '18

As list administrator, your authorization is requested for the following mailing list posting: List: nordwest(a)lists.ffnw.de From: wolfgang(a)ziffels.de Subject: The message is being held because: Message contains administrivia Message has no subject At your convenience, visit your dashboard to approve or deny the request.

1 0

FYI: Schwerwiegendes Schwachstelle in DSGVO-Plugin für WordPress
by Bjoern Franke 09 Nov '18

09 Nov '18

https://www.heise.de/security/meldung/Schwerwiegendes-Schwachstelle-in-DSGV…

2 2

Fwd: Systemd is bad parsing and should feel bad [security] [systemd]
by Jan-Tarek Butt 30 Oct '18

30 Oct '18

FYI Via: https://blog.erratasec.com/2018/10/systemd-is-bad-parsing-and-should-feel.h… Systemd has a remotely exploitable bug in it's DHCPv6 client. That means anybody on the local network can send you a packet and take control of your computer. The flaw is a typical buffer-overflow. Several news stories have pointed out that this client was written from scratch, as if that were the moral failing, instead of reusing existing code. That's not the problem. The problem is that it was written from scratch without taking advantage of the lessons of the past. It makes the same mistakes all over again. In the late 1990s and early 2000s, we learned that parsing input is a problem. The traditional ad hoc approach you were taught in school is wrong. It's wrong from an abstract theoretical point of view. It's wrong from the practical point of view, error prone and leading to spaghetti code. The first thing you need to unlearn is byte-swapping. I know that this was some sort epiphany you had when you learned network programming but byte-swapping is wrong. If you find yourself using a macro to swap bytes, like the be16toh() macro used in this code, then you are doing it wrong. But, you say, the network byte-order is big-endian, while today's Intel and ARM processors are little-endian. So you have to swap bytes, don't you? No. As proof of the matter I point to every other language other than C/C++. They don't don't swap bytes. Their internal integer format is undefined. Indeed, something like JavaScript may be storing numbers as a floating points. You can't muck around with the internal format of their integers even if you wanted to. An example of byte swapping in the code is something like this: In this code, it's taking a buffer of raw bytes from the DHCPv6 packet and "casting" it as a C internal structure. The packet contains a two-byte big-endian length field, "option->len", which the code must byte-swap in order to use. Among the errors here is casting an internal structure over external data. From an abstract theory point of view, this is wrong. Internal structures are undefined. Just because you can sort of know the definition in C/C++ doesn't change the fact that they are still undefined. From a practical point of view, this leads to confusion, as the programmer is never quite clear as to the boundary between external and internal data. You are supposed to rigorously verify external data, because the hacker controls it. You don't keep double-checking and second-guessing internal data, because that would be stupid. When you blur the lines between internal and external data, then your checks get muddled up. Yes you can, in C/C++, cast an internal structure over external data. But just because you can doesn't mean you should. What you should do instead is parse data the same way as if you were writing code in JavaScript. For example, to grab the DHCP6 option length field, you should write something like: The thing about this code is that you don't know whether it's JavaScript or C, because it's both, and it does the same thing for both. Byte "swapping" isn't happening. We aren't extracting an integer from a packet, then changing it's internal format. Instead, we are extracting two bytes and combining them. This description may seem like needless pedantry, but it's really really important that you grok this. For example, there is no conditional macro here that does one operation for a little-endian CPU, and another operation for a big-endian CPU -- it does the same thing for both CPUs. Whatever words you want to use to describe the difference, it's still profound and important. The other thing that you shouldn't do, even though C/C++ allows it, is pointer arithmetic. Again, it's one of those epiphany things C programmers remember from their early days. It's something they just couldn't grasp until one day they did, and then they fell in love with it. Except it's bad. The reason you struggled to grok it is because it's stupid and you shouldn't be using it. No other language has it, because it's bad. I mean, back in the day, it was a useful performance optimization. Iterating through an array can be faster adding to pointer than incrementing an index. But that's virtually never the case today, and it just leads to needless spaghetti code. It leads to convoluted constructions like the following at the heart of this bug where you have to both do arithmetic on the pointer as well as on the length which you are checking against. This nonsense leads to confusion and ultimately, buffer overflows. In a heckofalot of buffer overflows over the years, there's a construct just like this lurking near the bug. If you are going to do a rewrite of code, then this is a construct you need to avoid. Just say no to pointer arithmetic. In my code, you see a lot of constructs where it's buf, offset, and length. The buf variable points to the start of the buffer and is never incremented. The length variable is the max length of the buffer and likewise never changes. It's the offset variable that is incremented throughout. Because of simplicity, buffer overflow checks become obvious, as it's always "offset + x < length", and easy to verify. In contrast, here is the fix for the DHCPv6 buffer overflow. That this is checking for an external buffer overflow is less obvious: Now let's look at that error code. That's not what ENOBUFS really means. That's an operating system error code that has specific meaning about kernel buffers. Overloading it for userland code is inappropriate. That argument is a bit pedantic I grant you, but that's only the start. The bigger issue is that it's identifying the symptom not the problem. The ultimate problem is that the code failed to sanitize the original input, allowing the hacker to drive computation this deep in the system. The error isn't that the buffer is too small to hold the output, the original error is that the input was too big. Imagine if this gets logged and the sysadmin reviewing dmesg asks themselves how they can allocate bigger buffers to the DHCP6 daemon. That is entirely the wrong idea. Again, we go back to lessons of 20 years that this code ignored, the necessity of sanitizing input. Now let's look at assert(). This is a feature in C that we use to double-check things in order to catch programming mistakes early. An example is the code below, which is checking for programming mistakes where the caller of the function may have used NULL-pointers: This is pretty normal, but now consider this other use of assert(). This isn't checking errors by the programmer here, but is instead validating input. That's not what you are supposed to use asserts for. This are very different things. It's a coding horror that makes you shriek and run away when you see it. In my fact, that's my Halloween costume this year, using asserts to validate network input. This reflects a naive misunderstanding by programmers who don't understand the difference between out-of-band checks validating the code, and what the code is supposed to be doing validating input. Like the buffer overflow check above, EINVAL because a programmer made a mistake is a vastly different error than EINVAL because a hacker tried to inject bad input. These aren't the same things, they aren't even in the same realm. Conclusion Rewriting old code is a good thing -- as long as you are fixing the problems of the past and not repeating them. We have 20 years of experience with what goes wrong in network code. We have academic disciplines like langsec that study the problem. We have lots of good examples of network parsing done well. There is really no excuse for code that is of this low quality. This code has no redeeming features. It must be thrown away and rewritten yet again. This time by an experienced programmer who know what error codes mean, how to use asserts properly, and most of all, who has experience at network programming.

1 0