Effective October 27, 2012, online and email support for FuseSource products will move to Red Hat support channels. For more information, please see the JIRA Migration to Red Hat FAQ.
As of October 27th, please open all new issues in the Red Hat Customer Portal .
Issue Details (XML | Word | Printable)

Key: ESB-1673
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Major Major
Assignee: Guillaume Nodet
Reporter: Pat Fox
Votes: 0
Watchers: 2
Operations

If you were logged in you would be able to see more operations.
FUSE ESB

signatures of signed bundles in servicemix/data/cache not verified when reloaded into servicemix

Created: 23/Mar/12 05:34 PM   Updated: 27/Jul/12 10:01 AM
Component/s: Core
Affects Version/s: 4.4.1-fuse-02-02
Fix Version/s: None

File Attachments: 1. Zip Archive osgi_service_hack.zip (4 kB)
2. Java Archive File servicemix-exercises-osgi-service-2010.07.12.jar (8 kB)

Environment: tested on servicemix 4.4.1-03-06 with felix.framework.security 1.4.2
Issue Links:
Linked
 

External Issue URL: https://issues.apache.org/jira/browse/FELIX-3610


 Description  « Hide
The security framework (http://felix.apache.org/site/apache-felix-framework-security.html) seems to check the bundle contents against the signatures at bundle install time. However it is possible to modify the bundle in the servicemix/data/cache and this does not throw any security exceptions when it is reloaded. For scenario where bundles are deployed to servicemix instances that are not on a trusted machine, the signed bundle if tampered with, should throw a security exception at the point that this bundle is reloaded into memory.

How to Test

I updated my signed bundle in "../apache-servicemix-4.4.1-fuse-03-06/data/cache/bundle219/version0.0/bundle.jar" with a new version of a class file. I restarted servicemix and I could see from the logging statement the new version of the class is picked up but no security exception is thrown.

When I tried to load a class manually from this tampered bundle using the standard java command:

java -cp servicemix-exercises-osgi-service-2010.07.12.jar com.fusesource.training.service.greet.impl.GreeterImpl
Exception in thread "main" java.lang.SecurityException: SHA1 digest error for com/fusesource/training/service/greet/impl/GreeterImpl.class
	at sun.security.util.ManifestEntryVerifier.verify(ManifestEntryVerifier.java:198)
	at java.util.jar.JarVerifier.processEntry(JarVerifier.java:212)
	at java.util.jar.JarVerifier.update(JarVerifier.java:199)
	at java.util.jar.JarVerifier$VerifierStream.read(JarVerifier.java:449)
	at sun.misc.Resource.getBytes(Resource.java:108)
	at java.net.URLClassLoader.defineClass(URLClassLoader.java:257)
	at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
	at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:247)

So that looks like the jar is definitely signed and should be throwing an exception when reread from the servicemix/data/cache folder.



 All   Comments   Change History      Sort Order: Ascending order - Click to sort in descending order
Pat Fox added a comment - 23/Mar/12 06:05 PM
servicemix-exercises-osgi-service-2010.07.12.jar is a signed sample osgi bundle
osgi_service_hack.zip contains an updated version of com/fusesource/training/service/greet/impl/GreeterImpl.class

instruction to replicate issue:

1)setup felix framework security as described in http://felix.apache.org/site/apache-felix-framework-security.html.

2) install osgi bundle in servicemix

osgi:install file:XXX.../jarsigning/servicemix-exercises-osgi-service-2010.07.12.jar

update cached bundle within servicemix :

jar -uvf /XXX../apache-servicemix-4.4.1-fuse-03-06/data/cache/bundle220/version0.0/bundle.jar *

3)Restart servicemix,

This should throw a "java.lang.SecurityException: SHA1 digest error for com/fusesource/training/service/greet/impl/GreeterImpl.class* or something similar BUT currently does not.

check the bundle is updated correctly:

To verify you have "tampered"/updated the bundle correctly you can try the following command on the updated bundle. This should result in the following exception if the version of the class does not match the signature contained in the manifest.mf file. (which is the case after the bundle is updated)

java -cp servicemix-exercises-osgi-service-2010.07.12.jar com.fusesource.training.service.greet.impl.GreeterImpl
Exception in thread "main" java.lang.SecurityException: SHA1 digest error for com/fusesource/training/service/greet/impl/GreeterImpl.class
	at sun.security.util.ManifestEntryVerifier.verify(ManifestEntryVerifier.java:198)
	at java.util.jar.JarVerifier.processEntry(JarVerifier.java:212)
	at java.util.jar.JarVerifier.update(JarVerifier.java:199)
	at java.util.jar.JarVerifier$VerifierStream.read(JarVerifier.java:449)
	at sun.misc.Resource.getBytes(Resource.java:108)
	at java.net.URLClassLoader.defineClass(URLClassLoader.java:257)
	at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
	at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:247)

Guillaume Nodet added a comment - 26/Jul/12 08:01 PM
FELIX-3610 has been fixed and it should take care of checking bundle signatures when the framework restarts.

Guillaume Nodet added a comment - 26/Jul/12 08:03 PM
Note that the certificates of the CodeSource have been correctly set with the fix for FELIX-3611

Guillaume Nodet added a comment - 27/Jul/12 10:01 AM
Fixed in 4.4 and 7.0 branches