Please create an account to participate in the Slashdot moderation system


Forgot your password?
Slashdot Deals: Cyber Monday Sale Extended! Courses ranging from coding to project management - all eLearning deals 20% off with coupon code "CYBERMONDAY20". ×

Comment Re:Not a vulnerability in Java Commons Library (Score 1) 115

readObject is not something on the server, it is just a method signature defined by the serializable interface in the Java standard. The vulnerable code needs to be on the server of course, or there is nothing to abuse. The vulnerable code is in the Apache commons library, which has a class that implements serializable and therefore provides a readObject method, that can be abused.

But then you write something like "Serialized objects in Java is no difference than SOAP requests or JSON objects, or CORBA or other means to do RPC/RMI". But that is completely wrong in this context. The reason we have this bug is exactly because there is a difference from java serialization and all of the others that you mention. And that difference is that the serialization data includes arbitrary class names that allows the attacker to cause your code to load _any_ class that implements the serializable interface, no matter if that has anything to do with what you are working with here or not.

If you use JSON you will not have that. JSON can only cause strings, numbers, arrays and hashmaps to load.

This is also wrong: "Finally: serialized objects are just data, they contain no code. So there is nothing to execute. If you read the article, you see: the only code executed is the "readObject" method that already is on the server!!" - yes the exploit is in a readObject implementation, but that exploit allows the attacker to transmit arbitrary code and have it executed. Code that was in no way on the server already.

"First of all: there is no outside code executed when you transfer an object, the article is wrong with that. So you need a way to execute your code. The only way I can imagine is" - or the way the article describes. Which is not a derived object. He sends a serialization of a completely different object, namely the vulnerable class in Apache commons. The deserialization in Java just returns "Object" - there is no expectation here that the returned object be of the type that you, the programmer, expects. You will then of course get a class cast exception if you just cast it, or your code will notice something is not right if you do a isInstanceOf on it. But by then it is too late, he already had his custom code executed by Apache commons when the readObject method in there was called.

You need to know absolutely nothing about the system you want to attack. You only need two things, one is for the system to be vulnerable (=Apache commons needs to be on the classpath) and the other is that you need to find something the system serializes. You do not need to care about what it is that it serializes, because you will provide it with your hacked object, and the deserialization will fail but by then you already got what you want.

So if your web application does not use serialization the second prerequisite will fail and you are safe. But if you did something like putting a serialized object into a cookie, then you are done for.

Comment Re:Not a vulnerability in Java Commons Library (Score 1) 115

Finally: serialized objects are just data, they contain no code. So there is nothing to execute. If you read the article, you see: the only code executed is the "readObject" method that already is on the server!!

Did YOU read the article? The serialized objects are just data - well except if someone made a readObject that as part of the deserialization process executes steps based on that data. Programs are just data.

The "bug" is that someone did exactly that and put it into a very common library. If you have that library on your classpath, and chances are very high that you do, then you have no defense against this. You lose the moment you try to deserialize the data. It does not matter that you are expecting the data to deserialize to something completely different.

Say you make a class called UserInfo and put that into a cookie using serialization. If you did that, you are a goner. There is no way you can deserialize that cookie without risking that somebody replaced the cookie value with serialized data from Apache commons. You will not know that it is not actually UserInfo data anymore until after he rooted your system.

The only solution is to a) do not deserialize data that could be modified by an adversary. Or b) if you must, make sure Apache commons is not on the classpath while you do so (could be done with a custom classloader).

Personally I would ditch the build in java serialization and use another serialization library, one which does not allow arbitrary class names in the serialization data. I switched to Scala long ago and in the Scala world most serialization libraries do not use reflection to (de)serialize, and therefore fulfill that requirement.

Comment Re:Everyone needs an address so you can be tracked (Score 1) 435

Port numbers is only useful and needed if you are dealing with carrier NAT. That is NAT performed by the ISP, such that multiple customers share the same ISP. This happens to be somewhat common with apartment networks.

If RIAA/MPAA records the address 2001:db8:a55:beef::2af6 only the "2001:db8:a55:beef" part is actually useful. The remaining part of the address will typically be a randomized privacy extension address. They are therefore still unable to prove which machine was used to download the content.

If you are one of the persons that want to use easy to remember addresses, you can still use privacy extensions. With IPv6 it is normal to have many address on each computer. You can have your easy to remember address (2001:db8:a55::2) that you use for ingoing connections. And the machine will prefer the random privacy extension address for outgoing connections (2001:db8:a55::9b43:82dd:2239:10bc - right now but in an hour it will be completely different).

Comment Re:Where's IPv6 then? (Score 1) 435

There is also some big sites that are available:

baldur@ballerup1:~$ for i in; do ping6 -c1 -n $i | grep bytes; done
PING 56 data bytes
64 bytes from 2a00:1450:4005:801::1000: icmp_seq=1 ttl=50 time=28.8 ms
PING 56 data bytes
64 bytes from 2a03:2880:20:4f06:face:b00c:0:1: icmp_seq=1 ttl=43 time=191 ms
PING 56 data bytes
64 bytes from 2a01:578:3::36e4:ea94: icmp_seq=1 ttl=46 time=38.0 ms
PING 56 data bytes
64 bytes from 2a02:26f0:103:186::22df: icmp_seq=1 ttl=54 time=22.3 ms
PING 56 data bytes
64 bytes from 2400:cb00:2048:1::c629:d59d: icmp_seq=1 ttl=57 time=10.6 ms
PING 56 data bytes
64 bytes from 2001:4801:1221:101:1c10:0:f5:116: icmp_seq=1 ttl=43 time=127 ms
PING 56 data bytes
64 bytes from 2620:0:862:ed1a::1: icmp_seq=1 ttl=52 time=20.7 ms

The CDNs in there means that you will get some content over IPv6 even from sites that are not IPv6 enabled as such.

Comment Re:the circle of strife. (Score 1) 435

IPv6 Neighbour Discovery protocol (ND) is the protocol used by IPv6 hosts to find each other. It is the IPv6 equivalent of ARP. And ND is based on multicast. Without multicast, nothing would work with IPv6.

An IPv4 host needs to use broadcast ARP packets to every host on the same network. This was fixed in IPv6, so each host uses the last 32 bits of its address as a multicast group. When you need to contact someone, you will take the last 32 bits of his address and then multicast your ND packets to that multicast group. That way only hosts that share the same last 32 bits will receive the ND packet. This dramatically reduces the amount of broadcast/multicast chatter received by each host.

The downside is that it only works on networks with MLD enabled switches. That is very rare. Without MLD the system will fall back to broadcast.

But just to point out that you are wrong to believe that multicast is experimental when in fact it was baked in from the very start.

Comment Re:Everyone needs an address so you can be tracked (Score 1) 435

You need to read up on IPv6 privacy extensions:

Your computer will generate a random IPv6 address and change that random address at regular intervals (typically a few hours before it changes). Therefore they will be unable to track the exact computer, because there is no way to know which computer had that random address at the time.

They will get you anyway due to cookies and device fingerprinting, but that is no different than the situation with IPv4 and NAT.

Also with carrier NAT ISPs in most countries are by law required to record the port numbers assigned to each user. Your IP might be shared with multiple other users, but as long they also recorded the port number, they will be able to find the user. RIAA and MPAA knows this - I get a ton of email from them every day complaining about users that download their stuff with Bittorrent and every complaint includes port numbers.

Comment Re:Move to the latest version? (Score 1) 435

Try "Network Prefix Translation" instead:

"This document describes a stateless, transport-agnostic IPv6-to-IPv6
      Network Prefix Translation (NPTv6) function that provides the
      address-independence benefit associated with IPv4-to-IPv4 NAT
      (NAPT44) and provides a 1:1 relationship between addresses in the
      "inside" and "outside" prefixes, preserving end-to-end reachability
      at the network layer."

Although personally I believe it is seldom needed. In practice a IPv6 home network can renumber every device within 30 seconds of the ISP changing the prefix on you. That is less time than it takes for your CPE router to reboot.

Comment Re:Move to the latest version? (Score 1) 435

Nope, all three protocols will work fine with any prefix size. Only SLAAC need a /64 prefix

If you did a /120 you would use RA to tell your network about it. You would then need to set the managed config flag, so your devices can use DHCPv6 to acquire an address. After getting an address through DHCPv6 the devices will use the DAD process to check that the address is unused. And they will use ND to be able to communicate with other devices.

Comment Re:Move to the latest version? (Score 1) 435

The majority of internet service providers will give you a /48 prefix. Meaning that you decide what to do with the remaining 80 bits. If you make them all zero, your IPv6 address can indeed be shorter than the typical IPv4.


2001:db8:123:: (that would be your router)
2001:db8:123::2 (that would be your web server or whatever).
2001:db8:123::3 (that would be your mail server or whatever).

Compare to: (that would be your router - and also your web/mail server because it is all you got).

Comment Re:Three years after Europe ran out? (Score 1) 435

Blocks less than a /24 are not routable on the Internet. For some reason it was RIPE that tested that with a loaned block from ARIN.

One can hope that ARIN will recognize the need to be able to route this on the internet as sufficient reason to get a /24 instead of a /28.

There is one other difference to the RIPE policy and that is the IPv6 requirement. There is no such requirement by RIPE. You will get your /22 from RIPE and you can continue to ignore IPv6 and just use it with carrier NAT or whatever. RIPE will ask you to take an IPv6 assignment as well, but they do not ask if you are going to use it for anything.

Comment Re:Move to the latest version? (Score 1) 435

You are wrong. My router does have DHCPv6 and so does every OS (Linux, Mac and Windows) on my network.

You will find that basically 100% of the new generation routers (those with 802.11ac radios) come with full fledged IPv6 support these days. Including DHCPv6 support.

As to the ISP that seems to depend entirely on what country you live in. Some countries have very high penetration now. The rest of the world will follow.

Comment Re:Move to the latest version? (Score 1) 435

They wont because my ISP makes static allocations to every customer. But if you have another ISP with a poor policy, then you can use a private range such as fd00::/64 for your internal network.

fd00::2 is shorter than if we are still at that...

Yes you are supposed to put in something random in the fd00 style address. But nothing stops you from ignoring that. It is just so that your VPN to your employer does not collide unnecessary with your home network, but if both of you choose to use the same range, you are no worse off than if the same thing happened on IPv4.

For the average customer this is no issue however. They are in don't care about IP-addresses boat. If the ISP changes your prefix, your internal network will just renumber too and nobody notices.

Comment Re:Move to the latest version? (Score 1) 435

Actually my IPv6 address is:


Notice how it is _exactly_ the length of your proposal? I also happen to be able to remember it...

Ok, it is the address of my router, from where I can do port forwards etc, just like we used to do. So if you ssh into that, you will get to my server.

My other devices have longer addresses. Such as 2a00:7660:349::2. Yes there is a thing called DHCPv6 that allows one to assign short addresses to devices.

And because the ISP only controls the first 48 bits of the address, every device of mine gets to have an IP address and I was the one that decided the parts that might need to be remembered (the "2" from before).

It is true that most people will just let their network do auto configuration, which will then result in random and long addresses. That is because these days people generally do not care about IP-addresses. But it is your option - you can get it nice and clean if you are one of the few that cares.

Yes, we will be going to OSI, Mars, and Pluto, but not necessarily in that order. -- Jeffrey Honig