Uploaded image for project: '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
    • Status: Resolved
    • Priority: 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

      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.

        Gliffy Diagrams

          Attachments

            Issue Links

              Activity

                People

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

                  Dates

                  • Created:
                    Updated:
                    Resolved: