[JBoss JIRA] (SECURITY-851) Base64Utils class is stripping leading zeroes from encoded bytes
by Josef Cacek (JIRA)
[ https://issues.jboss.org/browse/SECURITY-851?page=com.atlassian.jira.plug... ]
Josef Cacek updated SECURITY-851:
---------------------------------
Summary: Base64Utils class is stripping leading zeroes from encoded bytes (was: Base64Util class is stripping leading zeroes from encoded bytes)
> Base64Utils class is stripping leading zeroes from encoded bytes
> ----------------------------------------------------------------
>
> Key: SECURITY-851
> URL: https://issues.jboss.org/browse/SECURITY-851
> Project: PicketBox
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: PicketBox_4_0_21.Beta2
> Reporter: Josef Cacek
> Assignee: Josef Cacek
> Priority: Blocker
>
> Vault util is failing for some password/salt/iteration combinations because Base64Utils class strips zeroes from provided byte array.
> So if a user encodes a key with length 8 and the leading byte of the key is zero, then after decoding he only gets 7 (or less) bytes.
> For instance:
> {code}
> encode ( { 0, 81, 121, -37, 46, -64, 20, 114 } ) -> "1HUTikm1Ho"
> decode ("1HUTikm1Ho") -> { 81, 121, -37, 46, -64, 20, 114 }
> {code}
> As a result the PBEUtil will fail with javax.crypto.IllegalBlockSizeException.
> IMHO the same problem can occur on other places where the Base64Utils class is used (not only the Vault).
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 5 months
[JBoss JIRA] (WFCORE-36) CLI NullPointerException for Ctrl+D when prompted for username.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-36?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse resolved WFCORE-36.
------------------------------------
Resolution: Cannot Reproduce Bug
Can no longer reproduce.
> CLI NullPointerException for Ctrl+D when prompted for username.
> ---------------------------------------------------------------
>
> Key: WFCORE-36
> URL: https://issues.jboss.org/browse/WFCORE-36
> Project: WildFly Core
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CLI
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 1.0.0.Alpha4
>
>
> {code}
> [standalone@localhost:9990 /] [darranl@localhost bin]$ ./jboss-cli.sh
> You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
> [disconnected /] connect
> Username: java.lang.NullPointerException
> at org.jboss.aesh.console.Console.pushToStdOut(Console.java:227)
> at org.jboss.as.cli.impl.Console$Factory$1.print(Console.java:160)
> at org.jboss.as.cli.impl.CommandContextImpl.printLine(CommandContextImpl.java:704)
> at org.jboss.as.cli.impl.CommandContextImpl.error(CommandContextImpl.java:722)
> at org.jboss.as.cli.impl.CommandContextImpl.handleSafe(CommandContextImpl.java:647)
> at org.jboss.as.cli.impl.CommandContextImpl.interact(CommandContextImpl.java:1272)
> at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:254)
> at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.modules.Module.run(Module.java:312)
> at org.jboss.modules.Main.main(Main.java:460)
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 5 months
[JBoss JIRA] (SECURITY-851) Base64Util class is stripping leading zeroes from encoded bytes
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/SECURITY-851?page=com.atlassian.jira.plug... ]
RH Bugzilla Integration updated SECURITY-851:
---------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1125004
> Base64Util class is stripping leading zeroes from encoded bytes
> ---------------------------------------------------------------
>
> Key: SECURITY-851
> URL: https://issues.jboss.org/browse/SECURITY-851
> Project: PicketBox
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: PicketBox_4_0_21.Beta2
> Reporter: Josef Cacek
> Assignee: Josef Cacek
> Priority: Blocker
>
> Vault util is failing for some password/salt/iteration combinations because Base64Utils class strips zeroes from provided byte array.
> So if a user encodes a key with length 8 and the leading byte of the key is zero, then after decoding he only gets 7 (or less) bytes.
> For instance:
> {code}
> encode ( { 0, 81, 121, -37, 46, -64, 20, 114 } ) -> "1HUTikm1Ho"
> decode ("1HUTikm1Ho") -> { 81, 121, -37, 46, -64, 20, 114 }
> {code}
> As a result the PBEUtil will fail with javax.crypto.IllegalBlockSizeException.
> IMHO the same problem can occur on other places where the Base64Utils class is used (not only the Vault).
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 5 months
[JBoss JIRA] (WFCORE-36) CLI NullPointerException for Ctrl+D when prompted for username.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-36?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse moved WFLY-3209 to WFCORE-36:
----------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-36 (was: WFLY-3209)
Component/s: CLI
(was: CLI)
Fix Version/s: 1.0.0.Alpha4
(was: 9.0.0.CR1)
> CLI NullPointerException for Ctrl+D when prompted for username.
> ---------------------------------------------------------------
>
> Key: WFCORE-36
> URL: https://issues.jboss.org/browse/WFCORE-36
> Project: WildFly Core
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CLI
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 1.0.0.Alpha4
>
>
> {code}
> [standalone@localhost:9990 /] [darranl@localhost bin]$ ./jboss-cli.sh
> You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
> [disconnected /] connect
> Username: java.lang.NullPointerException
> at org.jboss.aesh.console.Console.pushToStdOut(Console.java:227)
> at org.jboss.as.cli.impl.Console$Factory$1.print(Console.java:160)
> at org.jboss.as.cli.impl.CommandContextImpl.printLine(CommandContextImpl.java:704)
> at org.jboss.as.cli.impl.CommandContextImpl.error(CommandContextImpl.java:722)
> at org.jboss.as.cli.impl.CommandContextImpl.handleSafe(CommandContextImpl.java:647)
> at org.jboss.as.cli.impl.CommandContextImpl.interact(CommandContextImpl.java:1272)
> at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:254)
> at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.modules.Module.run(Module.java:312)
> at org.jboss.modules.Main.main(Main.java:460)
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 5 months
[JBoss JIRA] (SECURITY-851) Base64Util class is stripping leading zeroes from encoded bytes
by Josef Cacek (JIRA)
Josef Cacek created SECURITY-851:
------------------------------------
Summary: Base64Util class is stripping leading zeroes from encoded bytes
Key: SECURITY-851
URL: https://issues.jboss.org/browse/SECURITY-851
Project: PicketBox
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: PicketBox_4_0_21.Beta2
Reporter: Josef Cacek
Assignee: Josef Cacek
Priority: Blocker
Vault util is failing for some password/salt/iteration combinations because Base64Utils class strips zeroes from provided byte array.
So if a user encodes a key with length 8 and the leading byte of the key is zero, then after decoding he only gets 7 (or less) bytes.
For instance:
{code}
encode ( { 0, 81, 121, -37, 46, -64, 20, 114 } ) -> "1HUTikm1Ho"
decode ("1HUTikm1Ho") -> { 81, 121, -37, 46, -64, 20, 114 }
{code}
As a result the PBEUtil will fail with javax.crypto.IllegalBlockSizeException.
IMHO the same problem can occur on other places where the Base64Utils class is used (not only the Vault).
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 5 months
[JBoss JIRA] (JGRP-1864) UDP unable to bind to ephemeral port: port out of range:65536
by Ion Savin (JIRA)
[ https://issues.jboss.org/browse/JGRP-1864?page=com.atlassian.jira.plugin.... ]
Ion Savin edited comment on JGRP-1864 at 7/31/14 8:53 AM:
----------------------------------------------------------
Running this on the CI machine triggers the same exception:
{code}
import java.net.DatagramSocket;
import java.net.Inet6Address;
import java.net.InetAddress;
import java.net.NetworkInterface;
import java.util.Enumeration;
public class Main {
public static void main(String[] args) throws Exception {
InetAddress inet6Addresses = getInet6Addresses();
System.out.println(inet6Addresses);
DatagramSocket datagramSocket = new DatagramSocket(4242, inet6Addresses);
datagramSocket.close();
}
private static InetAddress getInet6Addresses() throws Exception {
for (Enumeration<NetworkInterface> en = NetworkInterface.getNetworkInterfaces(); en.hasMoreElements();) {
NetworkInterface intf = en.nextElement();
for (Enumeration<InetAddress> enumIpAddr = intf.getInetAddresses(); enumIpAddr.hasMoreElements();) {
InetAddress addr = enumIpAddr.nextElement();
if (addr instanceof Inet6Address) {
return addr;
}
}
}
return null;
}
}
{code}
{noformat}
/fe80:0:0:0:f816:3eff:fe3b:55a9%2
Exception in thread "main" java.net.BindException: Cannot assign requested address
at java.net.PlainDatagramSocketImpl.bind0(Native Method)
at java.net.AbstractPlainDatagramSocketImpl.bind(AbstractPlainDatagramSocketImpl.java:95)
at java.net.DatagramSocket.bind(DatagramSocket.java:376)
at java.net.DatagramSocket.<init>(DatagramSocket.java:231)
at java.net.DatagramSocket.<init>(DatagramSocket.java:284)
at Main.main(Main.java:12)
{noformat}
was (Author: isavin):
Running this on the CI machine triggers the same exception:
{code}
package datagram_test;
import java.net.DatagramSocket;
import java.net.Inet6Address;
import java.net.InetAddress;
import java.net.NetworkInterface;
import java.util.Enumeration;
public class Main {
public static void main(String[] args) throws Exception {
InetAddress inet6Addresses = getInet6Addresses();
System.out.println(inet6Addresses);
DatagramSocket datagramSocket = new DatagramSocket(4242, inet6Addresses);
datagramSocket.close();
}
private static InetAddress getInet6Addresses() throws Exception {
for (Enumeration<NetworkInterface> en = NetworkInterface.getNetworkInterfaces(); en.hasMoreElements();) {
NetworkInterface intf = en.nextElement();
for (Enumeration<InetAddress> enumIpAddr = intf.getInetAddresses(); enumIpAddr.hasMoreElements();) {
InetAddress addr = enumIpAddr.nextElement();
if (addr instanceof Inet6Address) {
return addr;
}
}
}
return null;
}
}
{code}
{noformat}
/fe80:0:0:0:f816:3eff:fe3b:55a9%2
Exception in thread "main" java.net.BindException: Cannot assign requested address
at java.net.PlainDatagramSocketImpl.bind0(Native Method)
at java.net.AbstractPlainDatagramSocketImpl.bind(AbstractPlainDatagramSocketImpl.java:95)
at java.net.DatagramSocket.bind(DatagramSocket.java:376)
at java.net.DatagramSocket.<init>(DatagramSocket.java:231)
at java.net.DatagramSocket.<init>(DatagramSocket.java:284)
at Main.main(Main.java:12)
{noformat}
> UDP unable to bind to ephemeral port: port out of range:65536
> -------------------------------------------------------------
>
> Key: JGRP-1864
> URL: https://issues.jboss.org/browse/JGRP-1864
> Project: JGroups
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 3.4.4
> Reporter: Dan Berindei
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.4.5, 3.5
>
>
> It looks like {{UDP.createEphemeralDatagramSocket()}} swallows any errors it gets while creating the socket, and throws this exception after trying to bind to all ports in the 0 - 65535 range:
> {noformat}
> java.lang.IllegalArgumentException: port out of range:65536
> at java.net.InetSocketAddress.checkPort(InetSocketAddress.java:143)
> at java.net.InetSocketAddress.<init>(InetSocketAddress.java:185)
> at java.net.DatagramSocket.<init>(DatagramSocket.java:284)
> at org.jgroups.util.DefaultSocketFactory.createDatagramSocket(DefaultSocketFactory.java:62)
> at org.jgroups.protocols.UDP.createEphemeralDatagramSocket(UDP.java:429)
> at org.jgroups.protocols.UDP.createSockets(UDP.java:311)
> at org.jgroups.protocols.UDP.start(UDP.java:216)
> at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:966)
> at org.jgroups.JChannel.startStack(JChannel.java:889)
> at org.jgroups.JChannel._preConnect(JChannel.java:547)
> at org.jgroups.JChannel.connect(JChannel.java:282)
> at org.jgroups.JChannel.connect(JChannel.java:273)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.startJGroupsChannelIfNeeded(JGroupsTransport.java:200)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 5 months
[JBoss JIRA] (JGRP-1864) UDP unable to bind to ephemeral port: port out of range:65536
by Ion Savin (JIRA)
[ https://issues.jboss.org/browse/JGRP-1864?page=com.atlassian.jira.plugin.... ]
Ion Savin commented on JGRP-1864:
---------------------------------
Running this on the CI machine triggers the same exception:
{code}
package datagram_test;
import java.net.DatagramSocket;
import java.net.Inet6Address;
import java.net.InetAddress;
import java.net.NetworkInterface;
import java.util.Enumeration;
public class Main {
public static void main(String[] args) throws Exception {
InetAddress inet6Addresses = getInet6Addresses();
System.out.println(inet6Addresses);
DatagramSocket datagramSocket = new DatagramSocket(4242, inet6Addresses);
datagramSocket.close();
}
private static InetAddress getInet6Addresses() throws Exception {
for (Enumeration<NetworkInterface> en = NetworkInterface.getNetworkInterfaces(); en.hasMoreElements();) {
NetworkInterface intf = en.nextElement();
for (Enumeration<InetAddress> enumIpAddr = intf.getInetAddresses(); enumIpAddr.hasMoreElements();) {
InetAddress addr = enumIpAddr.nextElement();
if (addr instanceof Inet6Address) {
return addr;
}
}
}
return null;
}
}
{code}
{noformat}
/fe80:0:0:0:f816:3eff:fe3b:55a9%2
Exception in thread "main" java.net.BindException: Cannot assign requested address
at java.net.PlainDatagramSocketImpl.bind0(Native Method)
at java.net.AbstractPlainDatagramSocketImpl.bind(AbstractPlainDatagramSocketImpl.java:95)
at java.net.DatagramSocket.bind(DatagramSocket.java:376)
at java.net.DatagramSocket.<init>(DatagramSocket.java:231)
at java.net.DatagramSocket.<init>(DatagramSocket.java:284)
at Main.main(Main.java:12)
{noformat}
> UDP unable to bind to ephemeral port: port out of range:65536
> -------------------------------------------------------------
>
> Key: JGRP-1864
> URL: https://issues.jboss.org/browse/JGRP-1864
> Project: JGroups
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 3.4.4
> Reporter: Dan Berindei
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.4.5, 3.5
>
>
> It looks like {{UDP.createEphemeralDatagramSocket()}} swallows any errors it gets while creating the socket, and throws this exception after trying to bind to all ports in the 0 - 65535 range:
> {noformat}
> java.lang.IllegalArgumentException: port out of range:65536
> at java.net.InetSocketAddress.checkPort(InetSocketAddress.java:143)
> at java.net.InetSocketAddress.<init>(InetSocketAddress.java:185)
> at java.net.DatagramSocket.<init>(DatagramSocket.java:284)
> at org.jgroups.util.DefaultSocketFactory.createDatagramSocket(DefaultSocketFactory.java:62)
> at org.jgroups.protocols.UDP.createEphemeralDatagramSocket(UDP.java:429)
> at org.jgroups.protocols.UDP.createSockets(UDP.java:311)
> at org.jgroups.protocols.UDP.start(UDP.java:216)
> at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:966)
> at org.jgroups.JChannel.startStack(JChannel.java:889)
> at org.jgroups.JChannel._preConnect(JChannel.java:547)
> at org.jgroups.JChannel.connect(JChannel.java:282)
> at org.jgroups.JChannel.connect(JChannel.java:273)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.startJGroupsChannelIfNeeded(JGroupsTransport.java:200)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 5 months
[JBoss JIRA] (WFLY-3697) Custom http handlers support
by Nicky Mølholm (JIRA)
[ https://issues.jboss.org/browse/WFLY-3697?page=com.atlassian.jira.plugin.... ]
Nicky Mølholm commented on WFLY-3697:
-------------------------------------
Okay thanks - that makes sense.
Btw: You could consider supporting "auto discovery" of annotated types too. So that pointing out the module would be enough - after which the extension will scan the module resources for certain, say, @GlobalHttpHandlers. I still like the XML declarative way too though - so this idea is by no means an alternative suggestion.
> Custom http handlers support
> ----------------------------
>
> Key: WFLY-3697
> URL: https://issues.jboss.org/browse/WFLY-3697
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Reporter: Tomaz Cerar
> Assignee: Tomaz Cerar
> Fix For: 9.0.0.Beta1
>
>
> We need support for custom handlers & filters
> something along the lines
> {code:xml}
> <handlers>
> <handler name="myhandler" class="full.class.name" module"full.module.name" />
> <handlers>
> <filters>
> <filter name="myfilter" class="full.class.name" module"full.module.name" />
> <filters>
> {code}
> There should also be a way to pass in arbitrary config options
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 5 months
[JBoss JIRA] (WFLY-3697) Custom http handlers support
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3697?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-3697:
-----------------------------------
This is just for undertow HttpHandlers as this stuff kicks in way before servlet container is started.
If you want servlet filters / servlets then just deploy war with them.
by undertow rules, HttpHandler can be filter or handler depending on its implementation, if it is last in chain it is handler, otherwise if it delegates to next handler it is filter.
> Custom http handlers support
> ----------------------------
>
> Key: WFLY-3697
> URL: https://issues.jboss.org/browse/WFLY-3697
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Reporter: Tomaz Cerar
> Assignee: Tomaz Cerar
> Fix For: 9.0.0.Beta1
>
>
> We need support for custom handlers & filters
> something along the lines
> {code:xml}
> <handlers>
> <handler name="myhandler" class="full.class.name" module"full.module.name" />
> <handlers>
> <filters>
> <filter name="myfilter" class="full.class.name" module"full.module.name" />
> <filters>
> {code}
> There should also be a way to pass in arbitrary config options
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 5 months
[JBoss JIRA] (JGRP-1864) UDP unable to bind to ephemeral port: port out of range:65536
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/JGRP-1864?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on JGRP-1864:
------------------------------------
Ion, could you issue a PR with your change to log the initial error instead of the "port out of range" error? I'd really like to get that in, even if we can't fix the underlying issue.
Bela, I have a hunch there's a problem if the JVM starts with {{java.net.preferXXX}} unset, and {{Util.ip_stack_type}} is initialized with {{StackType.IPv6}}, and then the program sets {{java.net.preferIPv4Stack=true}} before creating the JGroups channel. But I tried running our {{integrationtests/osgi}} test suite with {{java.net.preferIPv6Addresses=true}} to reproduce it on my machine, and I didn't get any failures.
> UDP unable to bind to ephemeral port: port out of range:65536
> -------------------------------------------------------------
>
> Key: JGRP-1864
> URL: https://issues.jboss.org/browse/JGRP-1864
> Project: JGroups
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 3.4.4
> Reporter: Dan Berindei
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.4.5, 3.5
>
>
> It looks like {{UDP.createEphemeralDatagramSocket()}} swallows any errors it gets while creating the socket, and throws this exception after trying to bind to all ports in the 0 - 65535 range:
> {noformat}
> java.lang.IllegalArgumentException: port out of range:65536
> at java.net.InetSocketAddress.checkPort(InetSocketAddress.java:143)
> at java.net.InetSocketAddress.<init>(InetSocketAddress.java:185)
> at java.net.DatagramSocket.<init>(DatagramSocket.java:284)
> at org.jgroups.util.DefaultSocketFactory.createDatagramSocket(DefaultSocketFactory.java:62)
> at org.jgroups.protocols.UDP.createEphemeralDatagramSocket(UDP.java:429)
> at org.jgroups.protocols.UDP.createSockets(UDP.java:311)
> at org.jgroups.protocols.UDP.start(UDP.java:216)
> at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:966)
> at org.jgroups.JChannel.startStack(JChannel.java:889)
> at org.jgroups.JChannel._preConnect(JChannel.java:547)
> at org.jgroups.JChannel.connect(JChannel.java:282)
> at org.jgroups.JChannel.connect(JChannel.java:273)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.startJGroupsChannelIfNeeded(JGroupsTransport.java:200)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 5 months