konwersja: nie autoryzowany `aaaa` @ error / constit.c / ReadImage / 453

Chcę utworzyć zdjęcie captcha za pomocą convertImageMagick.

I śledzę to , ale jest jakiś problem.

Wejście w mojej powłoce linux:

convert -background white -fill black -font FreeSerif-Bold -pointsize 36 label:'adfgh' ./test.png

Błąd jest następujący:

konwersja: brak autoryzacji adfgh@ error / constit.c / ReadImage / 453. konwersja: brak nazwy pliku obrazu ./test.png@ error / convert.c / ConvertImageCommand / 3015

My ImageMagick: Wersja: 6.7.2-7, instaluję go za pomocą yum install ImageMagick.

Nie mam pojęcia. Wszelkie porady proszę?

Uwaga: rozwiązanie w tej i innych odpowiedziach obejmuje wyłączenie środków bezpieczeństwa służących do naprawy luk w zabezpieczeniach wykonywania dowolnego kodu. Zobacz na przykład to związane z ghostscript i to ogłoszenie związane z ubuntu . Korzystaj z tych rozwiązań tylko wtedy, gdy dane wejściowe convertpochodzą z zaufanego źródła.

Korzystam z ImageMagick w php (v.7.1), aby pokroić plik PDF na obrazy.

Najpierw dostałem błędy takie jak:

Typ wyjątku: ImagickException

Komunikat wyjątku: brak autoryzacji ..... @ error / constit.c / ReadImage / 412

Po kilku zmianach /etc/ImageMagick-6/policy.xmlzaczynam dostawać błędy:

Typ wyjątku: ImagickException

Komunikat o wyjątku: nie można utworzyć pliku tymczasowego ..... Odmowa dostępu @ error / pdf.c / ReadPDFImage / 465

Moja poprawka :

W pliku /etc/ImageMagick-6/policy.xml(lub /etc/ImageMagick/policy.xml)

1. linia komentarza

   <!-- <policy domain="coder" rights="none" pattern="MVG" /> -->

2. zmień linię

   <policy domain="coder" rights="none" pattern="PDF" />

   do

   <policy domain="coder" rights="read|write" pattern="PDF" />

3. dodaj linię

   <policy domain="coder" rights="read|write" pattern="LABEL" />

Następnie uruchom ponownie serwer WWW (nginx, apache).

Używam wielokrotnie convertpolecenia ImageMagic do konwersji *.tifplików*.pdf pliki.

Nie wiem dlaczego, ale dzisiaj zacząłem otrzymywać następujący błąd:

convert: not authorized `a.pdf' @ error/constitute.c/WriteImage/1028.

Po wydaniu polecenia:

convert a.tif a.pdf

Po przeczytaniu powyższych odpowiedzi dokonałem edycji pliku /etc/ImageMagick-6/policy.xml

i zmieniłem linię:

policy domain="coder" rights="none" pattern="PDF" 

do

policy domain="coder" rights="read|write" pattern="PDF"

a teraz wszystko działa dobrze.

Mam „ImageMagick 6.8.9-9 Q16 x86_64 2018-09-28” na „Ubuntu 16.04.5 LTS”.

Uwaga: to rozwiązanie i każde inne rozwiązanie „edytuj plik policy.xml” wyłącza zabezpieczenia przed lukami w zabezpieczeniach przed wykonaniem dowolnego kodu w ImageMagick. Jeśli potrzebujesz przetworzyć dane wejściowe, których nie kontrolujesz w 100%, powinieneś użyć innego programu (nie ImageMagick).

Jeśli nadal tu jesteś, próbujesz edytować obrazy, nad którymi masz pełną kontrolę, wiesz, że są bezpieczne i nie mogą być edytowane przez użytkowników.

Tam jest /etc/ImageMagick/policy.xml plik instalowany przez yum. Nie zezwala na prawie wszystko (dla bezpieczeństwa i dla ochrony twojego systemu przed przeciążeniem wywołaniami ImageMagick).

Jeśli otrzymujesz ReadImagebłąd jak wyżej, możesz zmienić linię na:

<policy domain="coder" rights="read" pattern="LABEL" />

co powinno rozwiązać problem.

Plik zawiera sporo dokumentacji, więc powinieneś to przeczytać. Na przykład, jeśli potrzebujesz więcej uprawnień, możesz je połączyć w następujący sposób:

<policy domain="coder" rights="read|write" pattern="LABEL" />

... co jest lepsze niż usunięcie wszystkich kontroli uprawnień (tj. usunięcie lub skomentowanie linii).

Jeśli po instalacji ktoś musi to zrobić za pomocą jednego polecenia, uruchom to!

sed -i 's/<policy domain="coder" rights="none" pattern="PDF" \/>/<policy domain="coder" rights="read|write" pattern="PDF" \/>/g' /etc/ImageMagick-6/policy.xml

Odpowiedź z największą liczbą głosów (nie mam wystarczającej reputacji, aby dodać komentarz) sugeruje skomentowanie linii MVG, ale pamiętaj o tym:

CVE-2016-3714

ImageMagick obsługuje pliki „.svg / .mvg”, co oznacza, że ​​osoby atakujące mogą tworzyć kod w języku skryptowym, np. MSL (Magick Scripting Language) i MVG (Magick Vector Graphics), przesyłać go na serwer zamaskowany jako plik obrazu i wymuszać oprogramowanie do uruchamiania złośliwych poleceń po stronie serwera, jak opisano powyżej. Na przykład dodanie następujących poleceń do pliku i przesłanie go do serwera WWW korzystającego z wrażliwej wersji ImageMagick spowoduje uruchomienie polecenia „ls -la” na serwerze.

exploit.jpg:

push graficzny kontekst kontekstowy 0 0 640 480 wypełnij „url ( https://website.com/image.png " | ls "-la)" pop graficzny kontekst

I

Każda wersja poniżej 7.0.1-2 lub 6.9.4-0 jest potencjalnie podatna na atak, a strony, których to dotyczy, powinny jak najszybciej uaktualnić do najnowszej wersji ImageMagick.

Źródło

Po ostatniej aktualizacji mojego systemu Ubuntu 16.04 zacząłem również pojawiać się ten błąd podczas próby konwersji plików .ps w celu ich konwersji na pliki pdf.

Ta poprawka zadziałała dla mnie:

W biegu terminalowym:

sudo gedit /etc/ImageMagick-6/policy.xml

To powinno otworzyć plik policy.xml w edytorze tekstu gedit. Jeśli nie, twoja magia obrazu może zostać zainstalowana w innym miejscu. Następnie zmień

rights="none" 

do

rights="read | write" 

dla linii PDF, EPS i PS w dolnej części pliku. Zapisz i wyjdź, a magia obrazu powinna znów działać.

Wystarczy usunąć plik /etc/ImageMagick/policy.xml.

Po przeczytaniu kilku sugestii i połączeniu pomysłów, dla mnie konieczne były następujące zmiany w pliku /etc/ImageMagick-6/policy.xml:

<policy domain="coder" rights="read|write" pattern="PDF" />

... prawa = „brak” nie pomogło. ... wzór = „ETYKIETA” nie była konieczna. Chociaż nie pracuję z dużymi plikami png (tylko ~ 1 Mb), konieczne były również pewne zmiany limitów pamięci:

<policy domain="resource" name="memory" value="2GiB"/>

(zamiast 256Mib) i

<policy domain="resource" name="area" value="2GB"/>

(zamiast 128 MB)

Wystąpił ten błąd podczas próby konwersji pliku pdf do formatu jpg i rozwiązałem go przy użyciu tej metody: sudo vi /etc/ImageMagick*/policy.xml

zmiana:

domena strategii = prawa „kodera” = „brak” wzorzec = „PDF”

do:

domain domain = „coder” rights = „read | write” pattern = „PDF”

Źródło: http://realtechtalk.com/ImageMagick_Convert_PDF_Not_Authorized-2217-articles

Jeśli nie potrzebujesz obsługiwać plików rastrowych i plików PDF / PS / EPS za pomocą tego samego narzędzia, nie poluzuj zabezpieczeń ImageMagick.

Zamiast tego, zachowaj swoją głęboką obronę dla swoich aplikacji internetowych w nienaruszonym stanie, sprawdź, czy Ghostscript został załatany pod kątem wszystkich znanych -dSAFERluk, a następnie wywołaj go bezpośrednio.

gs -dSAFER -r300 -sDEVICE=png16m -o document-%03d.png document.pdf

• -dSAFER rezygnuje ze starszej kompatybilności „Uruchom Postscript uzyska pełne pozwolenie na interakcję ze światem zewnętrznym jako tryb pełnego języka programowania”.
• -r300 ustawia pożądaną DPI na 300 (domyślnie 72)
• -sDEVICEokreśla format wyjściowy ( inne opcje można znaleźć w sekcji Urządzenia instrukcji).
• -o jest skrótem od -dBATCH -dNOPAUSE -sOutputFile=
• W tej sekcji instrukcji Ghostscript podano kilka przykładowych formatów wyjściowych plików wieloplikowych, ale dla faktycznej definicji składni wskazuje ona dokumentację funkcji C printf (3) .

Jeśli renderujesz pliki EPS, dodaj, -dEPSCropaby nie dopasowywał wydruków do rozmiaru strony i nie służy -sDEVICE=pngalphado uzyskania przezroczystego tła.

Miałem również błąd error/constitute.c/ReadImage/453 podczas próby konwersji eps na gif z magią obrazu. Wypróbowałem rozwiązanie zaproponowane przez sNICkerssss, ale nadal miałem błędy (choć różne od pierwszego) e error/constitute.c/ReadImage/412 Rozwiązaniem problemu było umieszczenie readinnych wpisów

 <policy domain="coder" rights="read" pattern="PS" />
 <policy domain="coder" rights="read" pattern="EPS" />
 <policy domain="coder" rights="read" pattern="PDF" />
 <policy domain="coder" rights="read" pattern="XPS" />
 <policy domain="coder" rights="read|write" pattern="LABEL" />