12.07.19
Posted in Courtroom, Europe, Patents at 11:21 pm by Dr. Roy Schestowitz
35 U.S.C. § 101 would void corresponding USPTO patents
Summary: Law firms have gotten their way in Germany; instead of supporting the productive workers the patent system is nowadays promoting the litigation ‘industry’ and it ought to be corrected
CITING Sueddeutsche Zeitung (SZ), which used to cover European Patent Office (EPO) scandals, my online friend said that “BlackBerry wins German patent injunctions against Facebook, WhatsApp, Instagram over four (most likely invalid!) software patents” (he pinged Facebook and pinged “Ip2Innovate” about it).
“The Munich I Regional Court ordered a #patent injunction against #Facebook, #WhatsApp, #Instagram,” he said in another tweet. “It’s feature-specific but still, those are simply #softwarepatents that shouldn’t even be allowed in Europe. Germany needs patent reform badly! #BlackBerry is a troll.”
“It doesn’t matter if the software we developed is proprietary or Free software. It doesn’t even matter if we develop software or merely use it.”We’ve said that for years and we hope he will help us (Techrights, FFII etc.) fight back against fake software patents in Europe — an urgent and growing problem!
“I am stunned that the court didn’t stay all five cases over serious doubts concerning the validity of those patents,” he wrote. “When I looked at the claims of the patents-in-suit earlier this year, I quickly concluded that they’d all be highly likely to be annulled…”
This is a pretty decent article about a serious problem. It’s a good article about fake European Patents on software. If the Office grants invalid patents (IPs) that are abstract and incompatible with the EPC, we all suffer as a result. It doesn’t matter if the software we developed is proprietary or Free software. It doesn’t even matter if we develop software or merely use it.
“..they want lenient courts that accept — i.e. presume to be valid in a great rush — invalid patents and then grant injunctions for quick settlements (embargoes/sanctions can be ruinous enough to lead to it, irrespective of justice/truth).”Citing 5 European Patents, he names the following accused functionalities: showing two chat histories in parallel, automatically identifying user profiles containing partly identical data, sharing messages from the chat history, displaying chat history while text is being edited, chatting during gameplay.
There are actually European Patents on those things! Not only are these abstract; they are also trivial and there’s likely ample prior art.
From his post:
Sueddeutsche Zeitung (SZ), a Munich-based newspaper, reported yesterday evening on a set of Germany-wide patent injunctions that BlackBerry–once a smartphone maker, now basically a patent troll–just obtained against Facebook and its WhatsApp and Instagram subsidiaries over a total of four different patents covering chat features.
The injunction is provisionally enforceable. If BlackBerry posts a bond or makes a deposit, it can enforce the injunctions at this stage, though Facebook can appeal to the Munich Higher Regional Court and is, in parallel, challenging the validity of those patents before the Federal Patent Court of Germany. But Facebook has already told the media that the affected services–Facebook Messenger, WhatsApp, Instagram–wouldn’t go out of service in Germany: workarounds have been prepared, so the related features would have to be removed.
BlackBerry sued Facebook (with a focus on Facebook Messenger rather than the social media stream) and those two subsidiaries over five different patents, which I listed earlier this year and will list again further below.
[...]
I am stunned that the court didn’t stay all five cases over serious doubts concerning the validity of those patents. When I looked at the claims of the patents-in-suit earlier this year, I quickly concluded that they’d all be highly likely to be annulled by the Federal Patent Court of Germany (which also happens to be based in Munich, which is sort of the Capital of the Patent Movement, at least for Europe). That’s partly because software as such isn’t patent-eligible in Europe. While the courts rarely ever invalidate a patent as a whole on that basis, they do exclude any non-technical features from their novelty and non-obviousness analysis–and it’s hard to see how anything novel or inventive could be found in those patent claims that isn’t just software stuff without a technical effect. I already operated a chat service (as part of an online gaming network) in the 1990s and wrote an IRC client in 2000, so I know a lot of the prior art from hands-on experience.
What I have been able to find out is that BlackBerry, represented by Quinn Emanuel (a great firm that has not so great clients at times), had to narrow multiple patent claims-in-suit during the infringement proceedings just to address the court’s concerns over non-novelty. There are two problem with German patent infringement courts in the context to grant or deny a stay pending a nullity action. First, they apply an unreasonably high standard (and the “guru” from the Dusseldorf appeals court who has been promoting that high standard for many years more aggressively and fanatically than anyone else recently made dozens of employees of a small company lose their jobs–with Quinn Emanuel again on the enforcing side–over a patent subsequently held invalid). Second–though in many cases that’s even more important than the standard–they take only non-novelty (anticipation) arguments seriously and largely refuse to consider obviousness contentions (lack of inventive step) for no good reason (if they can rule on infringement without appointing expert witnesses, they certainly could also assess the existence of absence of an inventive step, but they just don’t want to).
Patent zealots from Mannheim, Düsseldorf and Munich (where António Campinos succeeded Battistelli) want us to think that everything is OK and even thriving. For the litigation ‘industry’? Sure. They don’t seem to care too much about the validity of granted patents; moreover, they want lenient courts that accept — i.e. presume to be valid in a great rush — invalid patents and then grant injunctions for quick settlements (embargoes/sanctions can be ruinous enough to lead to it, irrespective of justice/truth). █
Permalink
Send this to a friend
Posted in FUD, GNU/Linux, Security at 1:16 pm by Dr. Roy Schestowitz
Sometimes it morphes to “Linux” and a false description of what’s happening
Summary: What should have been a trivial bugfix in a variety of operating systems and bits of software — both proprietary and Free software — somehow became anti-Linux FUD, clickbait and worse
EARLIER in the week I saw a report about CVE-2019-14899. There was nothing exciting about it. I mentioned it briefly and then moved on. But the following day and especially two days later (after the announcement [1]) the press was absolutely flooding with reports, especially from insecurity companies and anti-Linux sites [2-22]. At times even deliberate lies were spread [23] (there are no attacks). See below a roughly chronological list/timeline. The initial report was calm and rational.
“The only shocking thing isn’t the bug but the level of media attention it has received.”When one carefully examines what’s at stake, the patching status (it’s not a zero-day hole), the severity and risk level etc. one begins to wonder what motivated all this attention. Much more severe issues are being discovered each week if not month.
We first mentioned this 2 or 3 days ago, without even filing it as a high-priority Daily Links pick. The only shocking thing isn’t the bug but the level of media attention it has received. This is not the first time such a thing happens. When similar issues affect Windows the media just describes these as “computer issues” or “PC”. █
Related/contextual items from the news:
-
Hi all,
I am reporting a vulnerability that exists on most Linux distros, and
other *nix operating systems which allows a network adjacent attacker
to determine if another user is connected to a VPN, the virtual IP
address they have been assigned by the VPN server, and whether or not
there is an active connection to a given website. Additionally, we are
able to determine the exact seq and ack numbers by counting encrypted
packets and/or examining their size. This allows us to inject data into
the TCP stream and hijack connections.
Most of the Linux distributions we tested were vulnerable, especially
Linux distributions that use a version of systemd pulled after November
28th of last year which turned reverse path filtering off. However, we
recently discovered that the attack also works against IPv6, so turning
reverse path filtering on isn't a reasonable solution, but this was how
we discovered that the attack worked on Linux.
Adding a prerouting rule to drop packets destined for the client's
virtual IP address is effective on some systems, but I have only tested
this on my machines (Manjaro 5.3.12-1, Ubuntu 19.10 5.3.0-23). This
rule was proposed by Jason Donenfeld, and an analagous rule on the
output chain was proposed by Ruoyu "Fish" Wang of ASU. We have some
concerns that inferences can still be made using slightly different
methods, but this suggestion does prevent this particular attack.
There are other potential solutions being considered by the kernel
maintainers, but I can't speak to their current status. I will provide
updates as I receive them.
I have attached the original disclosure I provided to
distros@vs.openwall.org and security@kernel.org below, with at least
one critical correction: I orignally listed CentOS as being vulnerable
to the attack, but this was incorrect, at least regarding IPv4. We
didn't know the attack worked against IPv6 at the time we tested
CentOS, and I haven't been able to test it yet.
William J. Tolley
Beau Kujath
Jedidiah R. Crandall
Breakpointing Bad &
University of New Mexico
*************************************************
**General Disclosure:
We have discovered a vulnerability in Linux, FreeBSD, OpenBSD, MacOS,
iOS, and Android which allows a malicious access point, or an adjacent
user, to determine if a connected user is using a VPN, make positive
inferences about the websites they are visiting, and determine the
correct sequence and acknowledgement numbers in use, allowing the bad
actor to inject data into the TCP stream. This provides everything that
is needed for an attacker to hijack active connections inside the VPN
tunnel.
This vulnerability works against OpenVPN, WireGuard, and IKEv2/IPSec,
but has not been thoroughly tested against tor, but we believe it is
not vulnerable since it operates in a SOCKS layer and includes
authentication and encryption that happens in userspace. It should be
noted, however, that the VPN technology used does not seem to matter
and we are able to make all of our inferences even though the responses
from the victim are encrypted, using the size of the packets and number
of packets sent (in the case of challenge ACKs, for example) to
determine what kind of packets are being sent through the encrypted VPN
tunnel.
We have already reported a related vulnerability to Android earlier
this year related to the issue, which resulted in the assignment of
CVE-2019-9461, however, the CVE strictly applies to the fact that the
Android devices would respond to unsolicited packets sent to the user’s
virtual IP address over the wireless interface, but this does not
address the fundamental issue of the attack and did not result in a
change of the reverse path settings of Android as of the most recent
security update.
This attack did not work against any Linux distribution we tested until
the release of Ubuntu 19.10, and we noticed that the rp_filter settings
were set to “loose” mode. We see that the default settings in
sysctl.d/50-default.conf in the systemd repository were changed from
“strict” to “loose” mode on November 28, 2018, so distributions using a
version of systemd without modified configurations after this date are
now vulnerable. Most Linux distributions we tested which use other init
systems leave the value as 0, the default for the Linux kernel.
We have described the procedure for reproducing the vulnerability with
Linux and included a section illustrating the differences in
architecture.
There are 3 steps to this attack:
1. Determining the VPN client’s virtual IP address
2. Using the virtual IP address to make inferences about active
connections
3. Using the encrypted replies to unsolicited packets to determine the
sequence and acknowledgment numbers of the active connection to hijack
the TCP session
There are 4 components to the reproduction:
1. The Victim Device (connected to AP, 192.168.12.x, 10.8.0.8)
2. AP (controlled by attacker, 192.168.12.1)
3. VPN Server (not controlled by attacker, 10.8.0.1)
4. A Web Server (not controlled by the attacker, public IP in a real-
world scenario)
The victim device connects to the access point, which for most of our
testing was a laptop running create_ap. The victim device then
establishes a connection with their VPN provider.
The access point can then determine the virtual IP of the victim by
sending SYN-ACK packets to the victim device across the entire virtual
IP space (the default for OpenVPN is 10.8.0.0/24). When a SYN-ACK is
sent to the correct virtual IP on the victim device, the device
responds with a RST; when the SYN-ACK is sent to the incorrect virtual
IP, nothing is received by the attacker.
To quickly demonstrate this difference, we use the nping commands on
the AP device running create_ap. The source IP is the gateway of our
AP, the destination IP is the virtual IP assigned to the tun interface
by the VPN client, ap0 is the interface create_ap created on the
attacker device, and the destination MAC is the victim’s wireless MAC
address.
For example:
The correct address generates a RST from the victim:
nping --tcp --flags SA --source-ip 192.168.12.1 --dest-ip 10.8.0.8 --
rate 3 -c 3 -e ap0 --dest-mac 08:00:27:9c:53:12
The incorrect address does not elicit a response from the victim:
nping --tcp --flags SA --source-ip 192.168.12.1 --dest-ip 10.8.0.9 --
rate 3 -c 3 -e ap0 --dest-mac 08:00:27:9c:53:12
Similarly, to test if there is an active connection for any given
website, such as 64.106.46.56, for example, we send SYN or SYN-ACKs
from 64.106.46.56 on port 80 (or 443) to the virtual IP of the victim
across the entire ephemeral port space of the victim. The correct four-
tuple will elicit no more than 2 challenge ACKs per second from the
victim, whereas the victim will respond to the incorrect four-tuple
with a RST for each packet sent to it.
To quickly test this, we suggest creating a netcat connection on the
victim device, such as this:
Netcat 64.106.46.56 80 -p 40404
The correct four-tuple generates challenge ACKs
nping --tcp --flags SA --source-ip 64.106.46.56 -g 80 --dest-ip
10.8.0.8 -p 40404 --rate 10 -c 10 -e ap0 --dest-mac 08:00:27:9c:53:12
The incorrect four-tuple generates a single RST for each packet sent:
nping --tcp --flags SA --source-ip 64.106.46.56 -g 80 --dest-ip
10.8.0.8 -p 40405 --rate 10 -c 10 -e ap0 --dest-mac 08:00:27:9c:53:12
Finally, once the attacker determined that the user has an active TCP
connection to an external server, we will attempt to infer the exact
next sequence number and in-window acknowledgment number needed to
inject forged packets into the connection. To find the appropriate
sequence and ACK numbers, we will trigger responses from the client in
the encrypted connection found in part 2. The attacker will continually
spoof reset packets into the inferred connection until it sniffs
challenge ACKs. The attacker can reliably determine if the packets
flowing from the client to the VPN server are challenge ACKs by looking
at the size and timing of the encrypted responses in relation to the
attacker's spoofed packets. The victim’s device will trigger a TCP
challenge ACK on each reset it receives that has an in-window sequence
number for an existing connection. For example, if the client is using
OpenVPN to exchange encrypted packets with the VPN server, then the
client will always respond with an SSL packet of length 79 when a
challenge ACK is triggered.
The attacker must spoof resets to different blocks across the entire
sequence number space until one triggers an encrypted challenge ACK.
The size of the spoof block plays a significant role in how long the
sequence inference takes, but should be conservative as to not skip
over the receive window of the client. In practice, when the attacker
thinks it sniffs an encrypted challenge-ACK, it can verify this is true
by spoofing X packets with the same sequence number. If there were X
encrypted responses with size 79 triggered, then the attacker knows for
certain it is triggering challenge ACKs (at most 2 packets of size 79
per second).
After the attacker has inferred the in-window sequence number for the
client's connection, they can quickly determine the exact sequence
number and in-window ACK needed to inject. First, they spoof empty
push-ACKs with the in-window sequence while guessing in-window ACK
numbers. Once the spoofed packets trigger another challenge-ACK, an in-
window ACK number is found. Finally, the attacker continually spoofs
empty TCP data packets with the in-window ACK and sequence numbers as
it decrements the sequence number after each send. The victim will
respond with another challenge ACK once the attacker spoofs the exact
sequence number minus one. The attacker can now inject arbitrary
payloads into the ongoing encrypted connection using the inferred ACK
and next sequence number.
This can be tested by observing the behavior from this sequence of
commands, continuing with the same four-tuple:
Using the four-tuple from the previous steps, we send RSTs in the
sequence number range in blocks of 50,000 until we trigger a challenge
ACK.
nping --tcp --flags R --source-ip 64.106.46.56 -g 80 --dest-ip 10.8.0.8
-p 40404 --rate 10 -c 10 -e ap0 --dest-mac 08:00:27:9c:53:12 --seq [SEQ
RANGE]
If the packet lands in-window, the victim will respond with at most 2
challenge ACKs per second. These packets are still encrypted and
originate from the virtual interface, unlike with Android, but we can
still determine the contents of these packets by their size. The
encrypted challenge ACK packets are larger than the encrypted RST
packets. You can run tcpdump on the victim machine to accelerate the
testing of his process by viewing the actual sequence and
acknowledgement numbers.
After we have found an in-window sequence number, we locate an in-
window acknowledgement by spoofing empty PSH-ACKs with the in-window
sequence number and guessing the acknowledgement number by dividing the
acknowledgement number space into eight blocks. In most instances,
seven of these blocks will trigger challenge ACKs, but one of them will
not, which allows us to quickly determine which block falls within the
acknowledgement window. We are interested in the block that does not
respond with a challenge ACK. This behavior can be observed by using an
in-window sequence number and an acknowledgement number in the block
containing the correct acknowledgement number.
nping --tcp --flags PA --source-ip 64.106.46.56 -g 80 --dest-ip
10.8.0.8 -p 40404 --rate 10 -c 10 -e ap0 --dest-mac 08:00:27:9c:53:12
-seq 12345678 --ack [ACK RANGE]
Finally, using the in-window sequence and acknowledgement numbers, we
spoof empty PSH-ACKs using the same in-windows acknowledgement number
and decrementing the sequence number until we trigger another challenge
ACK. This sequence number is one fewer than the next expected sequence
number. We can then arbitrarily inject data into the active TCP
connection.
Continuing with our toy example:
nping --tcp --flags PA --source-ip 64.106.46.56 -g 80 --dest-ip
10.8.0.8 -p 40404 --rate 10 -c 10 -e ap0 --dest-mac 08:00:27:9c:53:12
-seq [EXACT] --ack [IN-WINDOW] --data-string “hello,world.”
**Operating Systems Affected:
Here is a list of the operating systems we have tested which are
vulnerable to this attack:
Ubuntu 19.10 (systemd)
Fedora (systemd)
Debian 10.2 (systemd)
Arch 2019.05 (systemd)
Manjaro 18.1.1 (systemd)
Devuan (sysV init)
MX Linux 19 (Mepis+antiX)
Void Linux (runit)
Slackware 14.2 (rc.d)
Deepin (rc.d)
FreeBSD (rc.d)
OpenBSD (rc.d)
This list isn’t exhaustive, and we are continuing to test other
distributions, but made usere to cover a variety of init systems to
show this is not limited to systemd.
**Operating System Variations:
The behavior is slightly different on other operating systems. Here is
a summary of the differences:
Android: In the first phase of the attack, Android responds with
unencrypted RSTs to unsolicited SYN-ACKs for the correct port and ICMP
packets for the incorrect one. For the second phase, it will respond
with RSTs on the correct four-tuple.
MacOS/iOS: The first phase of the attack does not work as described
here, but you can use an open port on the Apple machine to determine
the virtual IP address. We use port 5223, which is used for iCloud,
iMessage, FaceTime, Game Center, Photo Stream, and push notifications
etc.
We know the phone will communicate with one of the push notification
servers on port 5223, and have observed that on MacOS, the port used on
the victim device is not the same as the port used to connect to the
VPN server, but is very close (in our testing it has always been within
10).
nping --tcp --flags SA --source-ip 17.57.144.[84-87] -g 5223 --dest-ip
10.8.0.8 -p [X] --rate 3 -c 3 -e ap0 --dest-mac 08:00:27:9c:53:12
For iOS devices, it does not follow this convention for choosing the
client’s source port, but always choose a port between ~48000-50000
(our testing on iOS 13.1 was between 48162-49555).
FreeBSD: The first two phases work essentially the same as Linux,
however, for the last phase, the ACK number is not needed at all, so
that piece of phase three can be skipped.
OpenBSD: OpenBSD responds to spoofed SYN packets to the correct virtual
IP with unencrypted RST packets, and the incorrect virtual IP elicits
unencrypted NTP packets or nothing at all for the first part of the
attack. For the second part, the responses are encrypted, but we can
still determine which packets are challenge ACKs from the packet size,
as with Linux. Connections can be reset by sending a RST with the
correct sequence number.
**Possible Mitigations:
1. Turning reverse path filtering on
Potential problem: Asynchronous routing not reliable on mobile devices,
etc. Also, it isn’t clear that this is actually a solution since it
appears to work in other OSes with different networking stacks. Also,
even with reverse path filtering on strict mode, the first two parts of
the attack can be completed, allowing the AP to make inferences about
active connections, and we believe it may be possible to carry out the
entire attack, but haven’t accomplished this yet.
2. Bogon filtering
Potential problem: Local network addresses used for vpns and local
networks, and some nations, including Iran, use the reserved private IP
space as part of the public space.
3. Encrypted packet size and timing
Since the size and number of packets allows the attacker to bypass the
encryption provided by the VPN service, perhaps some sort of padding
could be added to the encrypted packets to make them the same size.
Also, since the challenge ACK per process limit allows us to determine
if the encrypted packets are challenge ACKs, allowing the host to
respond with equivalent-sized packets after exhausting this limit could
prevent the attacker from making this inference.
We have prepared a paper for publication concerning this
vulnerability and the related implications, but intend to keep it
embargoed until we have found a satisfactory workaround. Then we will
report the vulnerability to oss-security@lists.openwall.com. We are
also reporting this vulnerability to the other services affected, which
also includes: Systemd, Google, Apple, OpenVPN, and WireGuard, in
addition to distros@vs.openwall.org for the operating systems affected.
Thanks,
William J. Tolley
Beau Kujath
Jedidiah R. Crandall
Breakpointing Bad &
University of New Mexico
-
Affecting most GNU/Linux distributions, as well as FreeBSD, OpenBSD, Android, iOS and macOS systems, the new security vulnerability could allow a local attacker to determine if another user is connected to a VPN (Virtual Private Network) server and whether or not there’s an active connection to a certain website.
The vulnerability (CVE-2019-14899) is exploitable with adjacent network access, which requires the attacker to have access to either the broadcast or collision domain of the vulnerable operating system, and lets attackers to hijack connections by injecting data into the TCP (Transmission Control Protocol) stream.
The vulnerability has been reported to work against various popular VPN solutions, including OpenVPN, IKEv2/IPSec, as well as WireGuard, and it doesn’t matter which VPN technology is being used, thus allowing attacker to determine the type of packets being sent through the encrypted VPN tunnel.
-
A bug in the way Unix-flavored systems handle TCP connections could put VPN users at risk of having their encrypted traffic hijacked, it is claimed.
The University of New Mexico team of William Tolley, Beau Kujath, and Jedidiah Crandall this week said they’ve discovered CVE-2019-14899, a security weakness they report to be present in “most” Linux distros, along with Android, iOS, macOS, FreeBSD, and OpenBSD. The upshot is, if exploited, encrypted VPN traffic can be potentially hijacked and disrupted by miscreants on the network.
To pull off the attack, the US-based posse says, a hacker would need to be “network adjacent” to their target, or control an access point on the victim’s local network. Once the victim connected to their VPN, the spy would be able to, for one thing, tamper with the TCP stream to do things like inject packets into the stream.
-
Security researchers found a new vulnerability allowing potential attackers to hijack VPN connections on affected *NIX devices and inject arbitrary data payloads into IPv4 and IPv6 TCP streams. They disclosed the security flaw tracked as CVE-2019-14899 to distros and the Linux kernel security team, as well as to others impacted such as Systemd, Google, Apple, OpenVPN, and WireGuard. The vulnerability is known to impact most Linux distributions and Unix-like operating systems including FreeBSD, OpenBSD, macOS, iOS, and Android. A currently incomplete list of vulnerable operating systems and the init systems they came with is available below, with more to be added once they are tested and found to be affected: Ubuntu 19.10 (systemd), Fedora (systemd), Debian 10.2 (systemd), Arch 2019.05 (systemd), Manjaro 18.1.1 (systemd), Devuan (sysV init), MX Linux 19 (Mepis+antiX), Void Linux (runit), Slackware 14.2 (rc.d), Deepin (rc.d), FreeBSD (rc.d), and OpenBSD (rc.d).
-
Security researchers found a new vulnerability allowing potential attackers to hijack VPN connections on affected *NIX devices and inject arbitrary data payloads into IPv4 and IPv6 TCP streams.
They disclosed the security flaw tracked as CVE-2019-14899 to distros and the Linux kernel security team, as well as to others impacted such as Systemd, Google, Apple, OpenVPN, and WireGuard.
-
The vulnerability — tracked as CVE-2019-14899 — resides in the networking stacks of multiple Unix-based operating systems, and more specifically, in how the operating systems reply to unexpected network packet probes.
-
Researchers have found a vulnerability on most Linux distros and *NIX devices which allow hackers to hijack the VPN connections and inject malicious data into the TCP stream.
The security researchers found the vulnerability in most Linux distributions and operating systems such as Linux, FreeBSD, OpenBSD, macOS, iOS, and Android.
-
The Breakpointing Bad cybersecurity research team from the University of New Mexico discovered and reported on a security flaw which could allow malicious actors to hack Virtual Private Network (VPN) connections.
William J. Tolley, Beau Kujath, and Jedidiah R. Crandall said the flaw impacts Linux, Android, macOS and other Unix-based operating systems and could allow attackers to sniff, hijack and tamper with VPN-tunnelled connections. The vulnerability was named CVE-2019-14899, with the researchers claiming it takes advantage of how operating systems handle unexpected network probes.
-
A number of Linux distributions, including Ubuntu, Fedora, and Debian, contain a newly discovered vulnerability that an attacker could use to determine whether an individual is using a VPN and then potentially hijack that encrypted connection.
A research team from the University of New Mexico discovered the vulnerability and developed an attack to exploit it. The attack has some specific requirements and relies on some analysis of the traffic going to and from the target device running the VPN client. The attack is confirmed to work against WireGuard and OpenVPN, but the researchers said that the VPN a victim is using doesn’t really matter. The main prerequisite for the attack to work is for the attacker to be able to send unsolicited packets to the victim’s VPN client.
-
Three researchers from the University of New Mexico and Breakpointing Bad have identified vulnerability in the way Unix and Linux-based operating systems like the macOS handle the TCIP connections. Researchers believe that vulnerability can specifically affect VPN users by hijacking encrypted traffic.
-
A team of cybersecurity researchers has disclosed a new severe vulnerability affecting most Linux and Unix-like operating systems, including FreeBSD, OpenBSD, macOS, iOS, and Android, that could allow remote ‘network adjacent attackers’ to spy on and tamper with encrypted VPN connections.
The vulnerability, tracked as CVE-2019-14899, resides in the networking stack of various operating systems and can be exploited against both IPv4 and IPv6 TCP streams.
Since the vulnerability does not rely on the VPN technology used, the attack works against widely implemented virtual private network protocols like OpenVPN, WireGuard, IKEv2/IPSec, and more, the researchers confirmed.
This vulnerability can be exploited by a network attacker — controlling an access point or connected to the victim’s network — just by sending unsolicited network packets to a targeted device and observing replies, even if they are encrypted.
-
A team of security researchers from the University of New Mexico has disclosed a new vulnerability that could allow attackers to probe devices and determine various details about the VPN (Virtual Private Network) connection status of a user.
The security vulnerability (CVE-2019-14899) appears to affect most GNU/Linux distributions, besides FreeBSD, OpenBSD, Android, iOS and macOS systems. William J. Tolley, one of the security researchers, explained in a post that the vulnerability could let attackers to determine if another user is connected to a VPN, the virtual IP address they have been assigned by the VPN server, and also sniff out whether or not there is an active connection to a given website.
-
One of the internet’s most popular free operating systems allowed attackers to bypass its authentication controls, effectively leaving the keys in the back door, according to an advisory released this week. The developers of the OpenBSD system have already patched the vulnerability.
OpenBSD allowed people access to its smtpd, ldapd, and radiusd programs – which send mail, allow access to user directories, and allow remote access to the computer system. All an attacker needed to do was enter a specific word prefixed by a hyphen as a username.
Qualys Research Labs found four bugs in BSD Authentication, which is the code that OpenBSD uses to authenticate users. Three of them were local privilege escalation bugs, while the other, CVE-2019-19521, bypassed the authentication system altogether. According to its security advisory, BSD Authentication supports four authentication styles: password, a one-time password mechanism called S/Key, and Yubico’s YubiKey hardware token.
-
Furthermore, the research team also identified the SEQ and ACK numbers from inspecting the encrypted packet size and number and managed to inject data into the TCP steam, which led to the hijacking of the connection. This means VPN technology was ineffective in preventing the attack since even encrypted packets could be assessed.
After testing on Manjaro 18.1.1, CentOS, and Ubuntu 19, researchers discovered that the exploit was applicable to both IPv4 and IPv6. Other systems that are vulnerable to exploitation include Void Linux, Debian 10.2, Slackware 14.2, Arch 2019.5, MX Linux 19, Deepin, Fedora, Devuan, FreeBSD, and OpenBSD. They will be testing the effectiveness of the exploit against Tor as well.
-
-
Insecurity experts at Breakpointing Bad have found aa new vulnerability allowing potential attackers to hijack VPN connections on affected *NIX devices and inject arbitrary data payloads into IPv4 and IPv6 TCP streams.
The security flaw tracked as CVE-2019-14899 to distros and the Linux kernel security team, as well as to others impacted such as Systemd, Google, Apple, OpenVPN, and WireGuard. The vulnerability is known to impact most Linux distributions and Unix-like operating systems including FreeBSD, OpenBSD, macOS, iOS, and Android.
A currently incomplete list of vulnerable operating systems and the init systems they came with is available below, with more to be added once they are tested and found to be affected: Ubuntu 19.10 (systemd), Fedora (systemd), Debian 10.2 (systemd), Arch 2019.05 (systemd), Manjaro 18.1.1 (systemd), Devuan (sysV init), MX Linux 19 (Mepis+antiX), Void Linux (runit), Slackware 14.2 (rc.d), Deepin (rc.d), FreeBSD (rc.d), and OpenBSD (rc.d).
-
A new vulnerability that could allow potential attackers to hijack VPN connections on affected NIX devices and inject arbitrary data payloads into IPv4 and Ipv6 TCP streams has been discovered by security researchers.
The researchers disclosed the security flaw they detected, tracked as CVE-2019-14899, to Linux distro makers, the Linux kernel security team and to others that are impacted including systemd, Google, Apple, OpenVPN and WireGuard.
-
Three researchers from Breakpointing Bad and the University of New Mexico have discovered a vulnerability that exists in Linux and Unix-like operating systems like Android and macOS. Given the tracking code “CVE-2019-14899”, the flaw resides in the routing table code and the TCP code that is present in these systems. The vulnerability allows an attacker to perform traffic analysis via clever use of encrypted DNS queries in conjunction with error messages, leading to the sniffing of open TCP connection information. The attack was discovered quite a while back, but the researchers disclosed it publicly now, and after they allowed the vendors some time to plug the holes.
-
-
In a coffee-shop scenario, attackers can hijack “secure” VPN sessions of those working remotely, injecting data into their TCP streams.
A vulnerability in most Linux distros has been uncovered that allows a network-adjacent attacker to hijack VPN connections and inject rogue data into the secure tunnels that victims are using to communicate with remote servers.
According to researchers at University of New Mexico and Breakpointing Bad, the bug (CVE-2019-14899), “allows…an attacker to determine if…a user is connected to a VPN, the virtual IP address they have been assigned by the VPN server, and whether or not there is an active connection to a given website.”
-
-
On Wednesday, security researchers from the University of New Mexico disclosed a vulnerability impacting most Linux distributions and Unix-like operating systems including FreeBSD, OpenBSD, macOS, iOS, and Android. This Linux vulnerability can be exploited by an attacker to determine if a user is connected to a VPN and to hijack VPN connections.
The researchers shared that this security flaw tracked as CVE-2019-14899, “allows a network adjacent attacker to determine if another user is connected to a VPN, the virtual IP address they have been assigned by the VPN server, and whether or not there is an active connection to a given website.” Additionally, attackers can determine the exact sequence and acknowledgment numbers by counting encrypted packets or by examining their size. With this information in hand, they can inject arbitrary data payloads into IPv4 and IPv6 TCP streams.
-
The attack has been reported to work against several popular VPN solutions, including OpenVPN, IKEv2/IPSec, and WireGuard.
However, the researchers are still testing their viability against Tor, as it works in a SOCKS layer and implements authentication and encryption that takes place in userspace.
“It should be noted, however, that the VPN technology used does not seem to matter and we are able to make all of our inferences even though the responses from the victim are encrypted, using the size of the packets and number of packets sent (in the case of challenge ACKs, for example) to determine what kind of packets are being sent through the encrypted VPN tunnel,” clarifies the research team.
Permalink
Send this to a friend
Posted in Deception, Europe, Patents at 5:55 am by Dr. Roy Schestowitz
August 2019: Managing IP as Team UPC’s Megaphone and Lobbying Front
Summary: It is pretty astounding that Team UPC (collective term for people who crafted and lobby for this illegal construct) is still telling us lies, even in the absence of underlying supportive facts, and pressure groups disguised as “news sites” latch onto anything to perpetuate an illusion of progress (even in the face of a growing number of major barriers)
THE European Patent Office (EPO) may seem quiet judging by lack of media coverage (nobody covered the outcome of the strike ballot; the fact is, five out of six voted for a strike). We’re supposed to think that António Campinos magically put an end to the Battistelli era just by virtue of coming to Munich.
EPO examiners are too smart to believe anything substantial changed (and/or for the better). The new guidelines, in effect since last month, compel examiners to grant more illegal software patents while their reward for this ‘production’ is actual reduction in renumeration. Where is the EPO going? “Collaborative Quality Improvements” (CQI), formerly known as “Team Collaboration Project,” shows that the Office isn’t really interested in examiners [1, 2]. They become more like official clerks than scientists. Their pay, their working conditions and employment benefits are accordingly gnawed away. They’re devalued as individuals and as professionals. Ask them. They’ll tell…
“EPO examiners are too smart to believe anything substantial changed (and/or for the better).”The litigation ‘industry’, on the other hand, is rather satisfied. Seeing the ‘growth’ in patents (a meaningless measure in its own right) they foresee lots of lawsuits, even frivolous ones. Seeing that ‘pesky’ courts get in their way, however (dismantling the European Patents), they still hope to remove that ‘annoying’ obstacle. They want a court that they better control with rules that they themselves drafted. That’s the UPC and the UPCA seems like a zombie document. It’s an ‘agreement’ that many people and even nations disagree on/with. Misled and bribed politicians, along with frightened and bribed press, helped Team UPC.
The litigation ‘industry’ and its lobbyists have not given up. They want us to think that UPCA being torpedoes is actually ‘great’! They say it works in their favour or to their benefit — something along the lines of celebrating the flu as a blessing in disguise, “making one stronger.”
AWA’s Niklas Mattsson and Louise Jonshammar (UPC hopefuls, based on the firm’s track record) have just published this piece (“German decision on UPC expected in early 2020″), echoing articles that said something similar about 2018, 2019 and so on. This headline is based solely on an improper telephone ‘interview’ — in a foreign language — with a judge that even the court sought to distance itself from [1, 2, 3]. We’ll come back to this in a moment. One must pay attention to the way Team UPC front group Managing IP squeezes this one ‘interview’ for weeks. They still talk about is every day. Managing IP has just spoken about “[a]n exclusive interview with Justice Huber of the German Federal Constitutional Court and the results of our survey on mental health and wellbeing were among the most read…”
“They lionise Justice Huber and shower him with praises, even fake badges and nonsense like “IP STARS”.”Managing IP is a patent zealots’ front group disguised as a “news” site. Its history when it comes to the UPC is very well documented here. They actively played a role and meddled in various ways. They met and spoke to Battistelli several times over the years. They set up pro-UPC lobbying events for the EPO. They published classic ‘fake news’ about the UPC (false predictions with no underlying source or evidence). We’ve also just noticed that over in Twitter they’re trying to ‘reward’ the judge with ‘honours’, e.g. here (there’s more). They lionise Justice Huber and shower him with praises, even fake badges and nonsense like “IP STARS”. Watch who they give these “crowns” to; it’s rather revealing. Watchtroll has just published “Gene Quinn Named One of the 50 Most Influential People in IP by Managing IP” and their list features Justice Huber (whom they elevate in Twitter). They’re also glorifying Microsoft’s Erich Andersen, who ‘reciprocates’ with a link in Twitter. Patent extortion against GNU/Linux ? Yes, reward! Chris Coons pushing for software patents and against patent justice (and courts)? Quick! Reward and special mention also!
“The people who nowadays publish their ‘reports’ could just go back to ‘uni’ and study how the patent systems actually work instead of just printing whatever law firms (which pay Managing IP) tell them to write.”Managing IP is basically a prank ‘news’ site, composed by people with no qualifications in the said area. As more writers leave (high turnover there) they hired increasingly less experienced people. We don’t want to name names here, but one can check and verify this for oneself. The people who nowadays publish their ‘reports’ could just go back to ‘uni’ and study how the patent systems actually work instead of just printing whatever law firms (which pay Managing IP) tell them to write.
So anyway, going back to AWA’s Niklas Mattsson and Louise Jonshammar, here’s what they say: (the firm apparently promoted this for a fee)
In an interview with IP industry publication Managing IP, Justice Huber of the German Federal Constitutional Court stated that the UK’s decision to leave the EU was of no concern to him and that, depending on the time it takes him and the other judges to deliberate, it is his intention for the Court to issue a decision on the complaint against German ratification of the Unified Patent Court Agreement (UPCA) in early 2020.
However, any decision from the German Federal Constitutional Court may still be delayed as the Justice Ministry previously expressed in a letter that the government will not ratify the UPCA until the implications of Brexit are clear.
Moreover, the court itself distanced itself from this inadequate ‘interview’, made memorable by use of words like “bullshit”. Why did a judge speak to a pressure group? Because he was pressured?
“Germany needs patent reform badly. The German patent litigation system is not just broken: it was ill-conceived and it’s been prone to abuse all along,” argues Florian Müller this month (days ago), stressing in his headline that “it would be unconstitutional in other countries” [1].
“This thing was ‘constructed’ (in a conspiratorial fashion) by law firms from France, Germany, and the UK (some of them have branches in several if not all of these countries).”“UPC will heavily influenced by Germans and their broken patent system, which favour patent trolls and is out of reach for SMEs,” Benjamin Henrion said about this article yesterday, followed by the hashtags #upc #germany and #trolls (seems apt). He has meanwhile also noted: “Unitary Software Patents ratification coming to Brussels Parliament, when do we get an opinion from the Belgian Constitutional Court about making adhoc rules of procedure for a court, which is against ECHR art6, justice made by LAW…”
He mentioned this to me yesterday and I told him that Brussels doesn’t matter to it; nobody expected Brussels (EU) to be the source of resistance, unlike the Spaniards, Czechs, Hungarians, Poles and so on. This thing was ‘constructed’ (in a conspiratorial fashion) by law firms from France, Germany, and the UK (some of them have branches in several if not all of these countries). Brussels is being an extension of EU authorities here, i.e. German/French Eurocrats.
“The EPO is not at all for SMEs!!! Leaks prove otherwise, as do basic sanity checks and scholarly work.”Suffice to say, those law firms don’t know or care about SMEs. They just don’t. They constantly lie about SMEs, as does the EPO. The EPO released several more tweets about “SMEs” this past week, a little #IPforSMEs fluff and then some more about #IPforSMEs (we’ll spare readers the shallow and repetitive content of these “tweets”). We’ve seen this more than once a day an average (used to be once in a couple of days or thereabouts, so it is increasing in frequency). Here’s some more tweeting about “SMEs”: “Up to two-thirds of inventions developed by SMEs & protected by European #patents are commercially exploited – around half exclusively by the SME itself & half with a partner, usually from another European country.”
That’s a rather meaningless and intentionally misleading bit of statistics. One might wrongly interpret that as two-thirds of SMEs being in favour of the status quo. The EPO together with the EUIPO recently released equally ridiculous claims. Causations and correlations get played like fire.
The EPO is not at all for SMEs!!! Leaks prove otherwise, as do basic sanity checks and scholarly work.
Yesterday the EPO tweeted: “Regular searches in #patent databases allow companies to monitor competitors and reveal opportunities for future innovations.”
“These are universal realities when it comes to the patent systems and that’s not unique to Europe.”“That also makes them liable with treble damages (willful infringement),” I responded, “but you leave that inconvenient fact out, don’t you? #IPforSMEs hashtag a total misfit here.”
“Even if you are not obliged to appoint a professional representative when applying for a #patent,” the EPO also tweeted yesterday, “it may still be helpful to consult one.”
“Very expensive and small businesses haven’t in-house ones,” I responded, “so they wind up wasting a fortune on advice from disloyal (external) people…”
These are universal realities when it comes to the patent systems and that’s not unique to Europe. Also check (based on publicly available data) what proportion of patents goes to SMEs.
“Also check (based on publicly available data) what proportion of patents goes to SMEs.”UPC would further damage SMEs, which barely if at all operate outside their home country and thus have a lot more to lose than to gain from multinational litigation.
Over at Kluwer Patent Blog (comments) Richard Gillespie wrote: “I find it surprising that the UPC has attracted so much more attention than the four EPO-related cases before the BVerfG – the result of these cases could have a far greater impact on out profession than the UPC-related case.”
And “Concerned observer” responded:
In my view, the answer to your question is that, in a large part, this is due to complacency that is based upon the assumption that the BVerfG will hesitate to reach a conclusion that could force Germany to exit such a long-established (and deeply embedded) international treaty as the EPC.
There may well be an element of truth in that assumption. However, whilst I do not claim any familiarity with constitutional law in Germany, it appears to me that another possible outcome is that the BVerfG’s ruling requires the German government to negotiate amendments to the EPC … which amendments could have significant effects. For this reason alone, I believe that it would be unwise to assume that none of the complaints in the EPO-related cases will be upheld.
Moreover, we already have examples of the independence of the EPO’s “judiciary” being compromised (in the Corcoran case, twice). Also, the Enlarged Board of Appeal is currently pondering a case (G 3/19) where the eventual ruling will provide direct evidence on the question of whether the EBA remains truly independent of the EPO’s President and Administrative Council. Given the (potential) breaches of the rule of law at the EPO in these cases, it seems to me that the BVerfG could well be justified in upholding at least some of the constitutional complaints relating to the EPO. Whether they will go as far as finding the current structure of the EPO unconstitutional remains to be seen … but it appears that there is no room for complacency on this point.
“Thanks for the reply,” Richard Gillespie later responded, “I think your [sic] right on this.”
“Concerned observer” later added:
I have been waiting years now for a plausible answer to the even more fundamental question of how the UPC can simultaneously meet the requirements of Article 267 TFEU (where preliminary references are only admissible if they are made by a “court or tribunal OF a Member State”) whilst being based upon an Agreement that allegedly establishes an INTERNATIONAL court (which permits the participation of a non-Member State).
Given the speed with which arguments have been generated by the UPC’s proponents on other points of law that threaten the viability of the UPC project, I believe that the long period over which not even a remotely plausible answer to this question has been provided can now be taken as strong evidence of the non-existence of any such answer. However it is evident that even non-compliance with EU law (ie the creation of a court that would destroy the integrity of the EU’s legal order) is no deterrent to those seeking to make the UPC a fait accompli.
My guess is that the proponents of the UPC are envisaging a situation in which the CJEU will keep the show on the road by delivering a judgement that, no matter how unconvincingly, glosses over the fundamental incompatibilities between the Agreement and EU law. Sadly, such a travesty is not as implausible as it ought to be. This is because there is evidence that, where there is enough political will, even immovable legal obstacles can be overcome (think, for example, of the decision of the Supreme Court of the Netherlands which ruled that recourse to ILO AT – which only accepts after the fact complaints from individuals – is an adequate recourse for those seeking to exercise their right to COLLECTIVE bargaining).
With this in mind, perhaps the most important question to answer here is why are the proponents of the UPC so seemingly confident that the political will is there to push their pet project over what should (for the sake of maintaining the integrity of the EU’s legal order) be an insurmountable obstacle? In other words, how can they be so confident that the politicians will support their project no matter what untold damage it might cause?
This is one of those cases where both the articles and all the comments are reasonable. Team UPC is more or less ‘shut out’ of this discussion, so there’s clarity, honesty, and common sense, not blind jingoism and lies (like whatever we see from AWA and Managing IP).
The above was only mentioned and quoted selectively by Team UPC. We supposed they don’t really want people to see it.
“Team UPC is more or less ‘shut out’ of this discussion, so there’s clarity, honesty, and common sense, not blind jingoism and lies (like whatever we see from AWA and Managing IP).”As a side (but nonetheless important) note, Henrion has taken some time off work to fight the UPC or will do so very soon.
They might rename (again) the UPC and retry for the next 10 years. We need to keep watching. “We need to go on campaign mode against to defeat the Unitary Patent monster,” Henrion explained. “Will take some days off to make an urgent plan of attack #swpat #upc #smes”
“Imagine the public reaction if Anthony Joshua claimed that his loss to Andy Ruiz II earlier this year was actually a “good” thing because of the ‘rematch’.”We don’t quite share his alarmist tone. We think that UPC died more than 2 years ago and those who still entertain it are “playing with the corpse” (as the saying goes). Henrion points to this page of feedback on EU policy that reveals patent trolls and their front groups (and law firms, e.g. Team UPC lobbyists). “Full of patent trolls here,” Henrion said, but yes, it’s hardly surprising. This is what we’ve been seeing for years and this is why UPC managed to get as far as it had (until its death). We’re not particularly concerned about the UPC anymore, seeing that its loudest proponents take very early retirement, IAM quit talking about it (almost), and the ringleader Ramsey has the audacity to say that all these setbacks are actually “good” (as if a loss is actually a win). “Failure is success if we learn from it,” Malcolm Forbes said. But what was learned by Team UPC? Nothing. Imagine the public reaction if Anthony Joshua claimed that his loss to Andy Ruiz II earlier this year was actually a “good” thing because of the ‘rematch’. █
Related/contextual items from the news:
-
I am presently researching the most appalling miscarriage of justice that ever occurred in a German patent case: dozens of people lost their jobs over a patent–held by a publicly-traded U.S. corporation–that later got invalidated by the Federal Patent Court of Germany (a problem commonly referred to as the “injunction gap”). That patent-in-suit is either (if construed broadly) clearly invalid or (if construed narrowly) not infringed by the accused product, but could not reasonably be held valid and infringed at the same time. The case raises questions not only about the outcome but also about the reasoning and the circumstances that led to it. There’s even a secondary question that reminds me of why Federal Circuit Chief Judge Rader resigned. But as the issues are so very serious, and the fallout from the facts being published might be massive and lasting, I’m making every humanly possible effort to analyze the matter with utmost diligence. That’s why it’s too early to provide names, but when the time is right, I will. The case number contains “39.” Interestingly, the presiding judge of the appellate panel that made the related decision mentioned it in passing last month, in a conspicuously defensive way, and the audience had no idea why he made a reference to a case they hadn’t ever heard of…
Germany needs patent reform badly. The German patent litigation system is not just broken: it was ill-conceived and it’s been prone to abuse all along, but abuse has become so rampant that the time is ripe for change. The situation is unsustainable, and the system doesn’t really deliver justice.
Right now there’s only one leading German patent infringement court of first instance that I believe does a stellar job under the circumstances, and that’s the Landgericht Mannheim (Mannheim Regional Court). Many years ago I thought the court was too plaintiff-friendly, but by now it’s my favorite one. To a far greater extent than their counterparts in other German venues, the Mannheim judges–whose understanding of technical issue is unsurpassed–have realized just how irresponsible it is to let patent holders enforce invalid patents all the time. In Mannheim, there are judges who deserve an honorary doctorate in (at least) radio frequency electronics and have the expertise to figure out when a patent is likely invalid as granted, coupled with the backbone to stay such cases (while we’re on this subject, I found out they recently also stayed one Broadcom lawsuit against BMW and one against Daimler, both over non-standard-essential patents). It will be interesting to see how they address the issue of component-level licensing in Nokia’s automotive SEP cases.
Permalink
Send this to a friend
Content is available under CC-BY-SA