New Java JDK released

[Roedy Green]

Java 1.7.9_51 was released today.

 

[Roedy Green]

1.7.0_51

oops. Sorry about that. For hints on installing see
http://mindprod.com/jgloss/jdk.html

 

[Silvio]

Java 1.7.9_51 was released today.

Did anyone try it to see what the impact of the restriction for server
sockets to the "ephemeral port range" is? I am running heaps of servlet
container processes on a cluster of Linux servers and this change seems
to prohibit listening on sockets in the range 1024-<way high>.

Why on earth did they do that?

Silvio

 

[markspace]

Before any rumors get started, here's what the release notes actually say:

"The default socket permissions assigned to all code including untrusted
code have been changed in this release. Previously, all code was able to
bind any socket type to any port number greater than or equal to 1024.
It is still possible to bind sockets to the ephemeral port range on each
system...

"Applications using datagram sockets or server tcp sockets (and a
security manager) may encounter security exceptions where none were seen
before. If this occurs, users should review whether the port number
being requested is expected, and if this is the case, a socket
permission grant can be added to the local security policy, to resolve
the issue."


So you might have to change the default configuration IF you are also
using the security manager, but that's it.

http://www.oracle.com/technetwork/java/javase/7u51-relnotes-2085002.html

 

[Silvio]

Before any rumors get started, here's what the release notes actually say:

"The default socket permissions assigned to all code including untrusted
code have been changed in this release. Previously, all code was able to
bind any socket type to any port number greater than or equal to 1024.
It is still possible to bind sockets to the ephemeral port range on each
system...

"Applications using datagram sockets or server tcp sockets (and a
security manager) may encounter security exceptions where none were seen
before. If this occurs, users should review whether the port number
being requested is expected, and if this is the case, a socket
permission grant can be added to the local security policy, to resolve
the issue."


So you might have to change the default configuration IF you are also
using the security manager, but that's it.

http://www.oracle.com/technetwork/java/javase/7u51-relnotes-2085002.html

Correct me if I am wrong but I read this as if my servers can no longer
listen on ports in the 1024-4000 range like they do now unless I dive
into some Java policy descriptor that I have never looked at before in
about 15 years of Java server side programming or manually change the
ephemeral port range on the server.

Sounds alarming to me. That is quite a disruption. I routinely have to
deploy servers onto cloud servers without having root access. And what
if I (or god help; my customer) do a Java version upgrade: do I have to
modify that policy thingy again?

Until someone explains to me why this change makes sense I call it a
stupid move. Reminds me of the Host header change they made to the URL
class somewhere around 1.7.0_26. That broke quite some reverse HTTP
proxy code that had been running for over ten years.

Silvio

 

[markspace]

Until someone explains to me why this change makes sense I call it a

I did explain it. Here's my question: did you try this on a test server
to see if it's actually a problem for you, or are you just making stuff
up when you say it's a problem?

 

[Silvio]

I did explain it. Here's my question: did you try this on a test server
to see if it's actually a problem for you, or are you just making stuff
up when you say it's a problem?

No, I did not try this because the Linux servers I have available are
not rolling release ones so I can not yet upgrade my Java. Additionally,
I am not able to test on all platforms I currently deploy to. That is
why I was asking if someone else did experiment, I welcome any
additional info.

I read the release notes and am worried that I may run into problems in
the near future, perhaps when one of my users does a system upgrade like
they have done so often. You make it seem like I am trying to cause a
panic but I just wanted to achieve two things: find out if someone could
either confirm or falsify my worries and make other people aware of the
policy change since I know by experience that many upgrade their Javas
without reading the release notes.

I still hope that I am wrong but if that is the fact then the release
note is at least vague. If not (and I think I can read, hence my
worries) then I wonder why such possibly disrupting changes are made in
minor releases with only a footnote in the release notes.

And you did not explain anything. You just copied the release note I
already read. If the change was made for security reasons (what else
could there be) then I would like some explanation about the security
breach that is closed with it.

 

[Roedy Green]

Did anyone try it to see what the impact of the restriction for server
sockets to the "ephemeral port range" is?

What is the advantage of this change? I presume it is some security
issue. Normally Java never does anything to break old apps.

 

[Silvio]

What is the advantage of this change? I presume it is some security
issue. Normally Java never does anything to break old apps.

Read my post: they have done it quite recently with no more than a vague
remark and (luckily) a system parameter to suppress the change. That
gave us the chance to temporarily get the old behaviour until we could
fix the code.

I sincerely hope they included another system property to suppress this
one. There is nothing mentioned in the release notes though.

 

[Kevin McMurtrie]

Correct me if I am wrong but I read this as if my servers can no longer
listen on ports in the 1024-4000 range like they do now unless I dive
into some Java policy descriptor that I have never looked at before in
about 15 years of Java server side programming or manually change the
ephemeral port range on the server.

Sounds alarming to me. That is quite a disruption. I routinely have to
deploy servers onto cloud servers without having root access. And what
if I (or god help; my customer) do a Java version upgrade: do I have to
modify that policy thingy again?

Until someone explains to me why this change makes sense I call it a
stupid move. Reminds me of the Host header change they made to the URL
class somewhere around 1.7.0_26. That broke quite some reverse HTTP
proxy code that had been running for over ten years.

Silvio

You're clearly not using the Security Manager if you haven't touched
security configurations. It's a whitelist that needs to be maintained
as features are added. This change wouldn't impact you.

 

[Arne Vajhøj]

No, I did not try this because the Linux servers I have available are
not rolling release ones so I can not yet upgrade my Java. Additionally,
I am not able to test on all platforms I currently deploy to. That is
why I was asking if someone else did experiment, I welcome any
additional info.

Are there any reason to believe that this change is platform specific?

If not then testing on one platform (like you development platform)
should give a decent indication.

And you would test on your deployment platforms when they
upgrade some day anyway.

I read the release notes and am worried that I may run into problems in
the near future, perhaps when one of my users does a system upgrade like
they have done so often. You make it seem like I am trying to cause a
panic but I just wanted to achieve two things: find out if someone could
either confirm or falsify my worries and make other people aware of the
policy change since I know by experience that many upgrade their Javas
without reading the release notes.

I still hope that I am wrong but if that is the fact then the release
note is at least vague. If not (and I think I can read, hence my
worries) then I wonder why such possibly disrupting changes are made in
minor releases with only a footnote in the release notes.

And you did not explain anything. You just copied the release note I
already read. If the change was made for security reasons (what else
could there be) then I would like some explanation about the security
breach that is closed with it.

I can not see what is vague.

I read Marks post and it took less time to develop examples
showing the topic under discussion than to write this post.

import java.io.IOException;
import java.net.ServerSocket;

public class SS {
public static void main(String[] args) throws IOException {
new ServerSocket(2000);
}
}

work on both _45 and _51.

import java.io.IOException;
import java.net.ServerSocket;
import java.rmi.RMISecurityManager;

public class SMSS {
public static void main(String[] args) throws IOException {
System.setSecurityManager(new RMISecurityManager());
new ServerSocket(2000);
}
}

works on _45 and throws an AccessControlException on _51.

Lots of people update Java without reading release notes. But
very few Java users actually uses a security manager. And if they
do then they will or at least should know how to read documentation.

The reason behind the change does not impact how it works or
what other changes may be necessary for the few using a security
manager.

Arne

 

[Arne Vajhøj]

oops. Sorry about that. For hints on installing see
http://mindprod.com/jgloss/jdk.html

Interesting page.

I wonder who can find the most errors on that page.

Arne

 

[Silvio]

You're clearly not using the Security Manager if you haven't touched
security configurations. It's a whitelist that needs to be maintained
as features are added. This change wouldn't impact you.

No, I am not using the Security Manager. My code runs on (mostly
dedicated) servers and I have never needed it.

Why does this change not impact me?

Cheers,

Silvio

 

[Silvio]

Are there any reason to believe that this change is platform specific?

Yes. The so called "ephemeral port range" differs per Linux
version/distro for example.

If not then testing on one platform (like you development platform)
should give a decent indication.

I could and I will once I have the time. But I may be beaten to it by
one of my users.

And you would test on your deployment platforms when they
upgrade some day anyway.

No I wouldn't. I have continuous access to about 20% of my current
deployment platforms. Upgrading of a number of them happens outside of
my control. In fact, some older installations run under a SLA that
explicitly allows minor Java version upgrades (explicitly negotiated by
the customers).

I can not see what is vague.

They are not very explicit in stating that server sockets without the
use of a SecurityManager are not affected. They only mention the SM
inside brackets.

I read Marks post and it took less time to develop examples
showing the topic under discussion than to write this post.

import java.io.IOException;
import java.net.ServerSocket;

public class SS {
public static void main(String[] args) throws IOException {
new ServerSocket(2000);
}
}

work on both _45 and _51.

import java.io.IOException;
import java.net.ServerSocket;
import java.rmi.RMISecurityManager;

public class SMSS {
public static void main(String[] args) throws IOException {
System.setSecurityManager(new RMISecurityManager());
new ServerSocket(2000);
}
}

works on _45 and throws an AccessControlException on _51.

Well, that confirms what Mark said and that is a good thing (unless you
are on Windows XP for example since 2000 is ephemeral there).
Unfortunately I do not create the server sockets myself but use about
half a dozen libraries that create in process embedded servers (among
which Jetty and H2Database) so I am not sure yet what these libraries do
under what circumstances.

 

[Silvio]

Yes. The so called "ephemeral port range" differs per Linux version/distro for example.

I'm not sure about that. "ephemeral port" is not a defined term. I assume
they mean the private (a.k.a. "dynamic") port range. This is defined in an
RFC and by the IANA
(<https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml>):

<quote>
...
Port numbers are assigned in various ways, based on three ranges: System
Ports (0-1023), User Ports (1024-49151), and the Dynamic and/or Private
Ports (49152-65535); the difference uses of these ranges is described in
[RFC6335].
...
</quote>

I did not introduce the term, it was used in the release notes and
Google reveals it is not an uncommon term. The IANA does set some
standard but Googling "ephemeral port range" revealed that Windows up to
XP, BSD and older Linux kernels use different ranges, sometimes even
dependant of the available memory (mentioned only for Linux). The Linux
machines I tried all seem to use the range 32768-61000.

 

[Michal Kleczek]

W dniu 2014-01-15 06:45, Roedy Green pisze:

Java 1.7.9_51 was released today.

And of course this is still not fixed:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8011811

All this "focusing" on security is pure crap if applying security
related patches is a PITA for users aware of security best practices.

 

[Joerg Meier]

Interesting page.

I wonder who can find the most errors on that page.

Considering he still hasn't fixed the multiple Windows issues that were
pointed out to him here over a year ago, it seems like listing them would
be a waste of everyones time.

Liebe Gruesse,
Joerg

 

[Joerg Meier]

No, I am not using the Security Manager. My code runs on (mostly
dedicated) servers and I have never needed it.

Why does this change not impact me?

Why would a change that explicitly says that it's a permissions change that
affects Sockets used together with a SecurityManager affect something
without a SecurityManager ? Are you also worried it will impact your file
reading, or array initializing ?

Liebe Gruesse,
Joerg

 

[Silvio]

Why would a change that explicitly says that it's a permissions change that
affects Sockets used together with a SecurityManager affect something
without a SecurityManager ? Are you also worried it will impact your file
reading, or array initializing ?

Liebe Gruesse,
Joerg

As I already stated I use a number of libraries to embed some servers in
my processes (HTTP/HTTPS, H2 database, SMTP, FTP) and do not know if any
of these employs a SecurityManager.

Ignored the wise crap.

 

[Knute Johnson]

import java.io.IOException;
import java.net.ServerSocket;
import java.rmi.RMISecurityManager;

public class SMSS {
public static void main(String[] args) throws IOException {
System.setSecurityManager(new RMISecurityManager());
new ServerSocket(2000);
}
}

I modified your code a little to use a plain SecurityManager and tested
it on my Windows 8.1. The ports 49151 and below throw the exception but
not above that.

Some fellow over on the Ubuntu users list just had his stock quote
program upchuck when he updated to _51 on U.