euca-bundle-image returns Odd-length string error

Bug #509562 reported by ehcpdeveloper
14
This bug affects 3 people
Affects Status Importance Assigned to Milestone
euca2ools
Fix Released
Undecided
Mitch Garnaat
euca2ools (Ubuntu)
Fix Released
Medium
Unassigned
Nominated for Lucid by Dave Walker
Maverick
Fix Released
Medium
Unassigned
eucalyptus (Ubuntu)
Invalid
Medium
Unassigned
Nominated for Lucid by Dave Walker
Maverick
Invalid
Medium
Unassigned

Bug Description

i use web frontend http://ip:8443 to control cloud,
i click store, karmic coala -> install
installer downloads image, but an error occurs:

Command 'euca-bundle-image' returned status code 1:
Checking image
Tarring image
Encrypting image
Traceback (most recent call last):
  File "/usr/bin/euca-bundle-image", line 226, in <module>
    main()
  File "/usr/bin/euca-bundle-image", line 204, in main
    encrypted_file, key, iv, bundled_size = euca.encrypt_image(tgz_file)
  File "/usr/lib/python2.6/dist-packages/euca2ools/__init__.py", line 533, in encrypt_image
    k=EVP.Cipher(alg='aes_128_cbc', key=unhexlify(key), iv=unhexlify(iv), op=1)
TypeError: Odd-length string

ProblemType: Bug
Architecture: amd64
Date: Tue Jan 19 12:20:21 2010
DistroRelease: Ubuntu 9.10
Package: eucalyptus-cc 1.6~bzr931-0ubuntu7.4
ProcEnviron:
 LANG=tr_TR.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-17.54-server
SourcePackage: eucalyptus
Uname: Linux 2.6.31-17-server x86_64

Revision history for this message
ehcpdeveloper (ehcpdeveloper) wrote :
Revision history for this message
Thierry Carrez (ttx) wrote :

This one is not store-specific, I hit it once doing regular image-bundling. Changing title to match that, and adding euca2ools as potentially-affected package.

summary: - eucalyptus cannot download and install images
+ euca-bundle-image returns Odd-length string error
Changed in eucalyptus (Ubuntu):
status: New → Confirmed
Changed in euca2ools (Ubuntu):
status: New → Confirmed
importance: Undecided → Medium
Changed in eucalyptus (Ubuntu):
importance: Undecided → Medium
Revision history for this message
ehcpdeveloper (ehcpdeveloper) wrote :

i want to state that, currently, I cannot use eucalyptus or ubuntu cloud services, in my server.

Revision history for this message
Dustin Kirkland  (kirkland) wrote :

Marking invalid against Eucalyptus, as Dan says the bug is in euca2ool (or perhaps the image-store-proxy).

Changed in eucalyptus (Ubuntu):
status: Confirmed → Invalid
Revision history for this message
Neil Soman (neilsoman) wrote :

I can't confirm this against euca2ools upstream. Is there a sample image that can be used stand alone with euca2ools in order to verify this?

Changed in euca2ools (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
Scott Moser (smoser) wrote :

I found the what is at fault here, the following program demonstrates the error:

#!/usr/bin/python
from M2Crypto import BN, EVP, RSA, util, Rand, m2, X509
from binascii import hexlify, unhexlify
i=0
while True:
   i=i+1
   try:
      iv = (hex(BN.rand(16 * 8))[2:34]).replace('L', 'c')
      uh = unhexlify(iv)
   except:
      print "found failure, i=%s, iv=%s len=(%s)\n" % (i,iv,len(iv))
      raise

basically,
  iv = (hex(BN.rand(16 * 8))[2:34]).replace('L', 'c')
is not guaranteed to create something that is consumable by unhexlify.
Run it, and you'll very quickly see something like:

$ /tmp/go.py
found failure, i=36, iv=3f99a2dfad8a6d936772bd181f8653c len=(31)

Traceback (most recent call last):
  File "/tmp/go.py", line 11, in <module>
    uh = unhexlify(iv)
TypeError: Odd-length string

Changed in euca2ools (Ubuntu):
status: Incomplete → Triaged
Revision history for this message
Scott Moser (smoser) wrote :

The problem was that the euca2ools/__init__.py was doing:
   iv = (hex(BN.rand(16 * 8,top=0)))[2:34]
then
   unhexlify(iv)

But BN.rand(16*8) is not guaranteed to return a number that is
represented by 32 hex digits. I suspect that the .replace('L','c') was
added to get around this issue. By specifying 'top=0' in the BN.rand
call, we guarantee that the number will have the top bit set.

I've ran the following snippet past i=40,000,000 . Without the fix in
place I never saw it run past 1000.

while True:
   i=i+1
   try:
      uh = unhexlify((hex(BN.rand(16 * 8,top=0)))[2:34])
   except KeyboardInterrupt:
      print "tried %i times, no failures yet" % i
   except:
      print "found failure, i=%s, iv=%s len=(%s)" % (i,iv,len(iv))
      sys.exit(1)

Revision history for this message
Scott Moser (smoser) wrote :

I've run the following with the fixed version and with the broken version:
rm -f my.img ;
truncate --size 1k my.img;
for((i=0;i<1000;i++)); do
  out=$(euca-bundle-image -i my.img 2>&1) || { echo "failed: ${out}"; break; } ;
  [ $(($i%10)) -eq 0 ] && echo i=$i;
done ;

the fixed has run to 1000 times, the broken has failed 5 times demonstrating this bug before reaching i=300.

Revision history for this message
Scott Moser (smoser) wrote :

I'm attaching the same patch against upstream euca2ools.

Changed in euca2ools:
status: New → Confirmed
Changed in euca2ools:
assignee: nobody → Mitch Garnaat (mitch-garnaat)
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package euca2ools - 1.2-0ubuntu11

---------------
euca2ools (1.2-0ubuntu11) maverick; urgency=low

  * euca-bundle-image: fix transient Odd-Length exception (LP: #509562)
 -- Scott Moser <email address hidden> Fri, 17 Sep 2010 12:14:30 -0400

Changed in euca2ools (Ubuntu):
status: Triaged → Fix Released
Revision history for this message
Scott Moser (smoser) wrote :

OK, my patch changes what was expected to be 32 bits of randomness to 31 bits of randomness.

Its probably not that big of a deal, but upstream should probably do:
- key = hex(BN.rand(16 * 8,top=0))[2:34]
+ key = hex(BN.rand(17 * 8,top=0))[3:35]

that will get the same 32 bits of randomness, but will still have the 32 bits of random number that were intended.

Revision history for this message
Scott Moser (smoser) wrote :

comment 12 contained a bad analysis.
The code that is now committed to maverick gets 31.5 hex chars of randomness rather than 32.
I'm not going to bother changing in maverick.

That said, the right code for upstream is probably something like:
      # get 17 bytes of randomness with top bit a '1'.
      # convert to a hex string like '0x<hex 34 digits>L'
      # then take the last 32 of the hex digits, giving 32 random hex chars
      iv = (hex(BN.rand(17 * 8,top=0)))[4:36]

I'm attaching a better patch for upstream.

Revision history for this message
Mitch Garnaat (mitch-garnaat) wrote :

I have merged this patch in upstream.

Changed in euca2ools:
status: Confirmed → Fix Committed
Changed in euca2ools:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.