FUSE ESB
  1. FUSE ESB
  2. ESB-1673

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

    Details

    • Type: Bug Bug
    • Status: Resolved Resolved
    • Priority: Major Major
    • Resolution: Done
    • Affects Version/s: 4.4.1-fuse-02-02
    • Fix Version/s: None
    • Component/s: Core
    • Labels:
      None
    • Environment:
      tested on servicemix 4.4.1-03-06 with felix.framework.security 1.4.2
    • Similar Issues:
      Show 10 results 

      Description

      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.

        Issue Links

          Activity

          Hide
          Pat Fox
          added a comment -

          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)
          
          Show
          Pat Fox
          added a comment - 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)
          Hide
          Guillaume Nodet
          added a comment -

          FELIX-3610 has been fixed and it should take care of checking bundle signatures when the framework restarts.

          Show
          Guillaume Nodet
          added a comment - FELIX-3610 has been fixed and it should take care of checking bundle signatures when the framework restarts.
          Hide
          Guillaume Nodet
          added a comment -

          Note that the certificates of the CodeSource have been correctly set with the fix for FELIX-3611

          Show
          Guillaume Nodet
          added a comment - Note that the certificates of the CodeSource have been correctly set with the fix for FELIX-3611
          Hide
          Guillaume Nodet
          added a comment -

          Fixed in 4.4 and 7.0 branches

          Show
          Guillaume Nodet
          added a comment - Fixed in 4.4 and 7.0 branches

            People

            • Assignee:
              Guillaume Nodet
              Reporter:
              Pat Fox
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: