Glibc ਵਿੱਚ Aurora OS ਡਿਵੈਲਪਰਾਂ ਦੁਆਰਾ ਤਿਆਰ ਕੀਤੀ ਗਈ memcpy ਕਮਜ਼ੋਰੀ ਲਈ ਇੱਕ ਫਿਕਸ ਸ਼ਾਮਲ ਹੈ

ਔਰੋਰਾ ਮੋਬਾਈਲ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ (ਓਪਨ ਮੋਬਾਈਲ ਪਲੇਟਫਾਰਮ ਕੰਪਨੀ ਦੁਆਰਾ ਵਿਕਸਤ ਸੈਲਫਿਸ਼ ਓਐਸ ਦਾ ਇੱਕ ਫੋਰਕ) ਦੇ ਡਿਵੈਲਪਰਾਂ ਨੇ ਇਸ ਨੂੰ ਖਤਮ ਕਰਨ ਬਾਰੇ ਇੱਕ ਉਦਾਹਰਣ ਵਾਲੀ ਕਹਾਣੀ ਸਾਂਝੀ ਕੀਤੀ। ਨਾਜ਼ੁਕ ਕਮਜ਼ੋਰੀ (CVE-2020-6096) Glibc ਵਿੱਚ, ਜੋ ਕਿ ਸਿਰਫ਼ ARMv7 ਪਲੇਟਫਾਰਮ 'ਤੇ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ। ਕਮਜ਼ੋਰੀ ਦਾ ਖੁਲਾਸਾ ਮਈ ਵਿੱਚ ਕੀਤਾ ਗਿਆ ਸੀ, ਪਰ ਹਾਲ ਹੀ ਵਿੱਚ ਇੱਕ ਹੱਲ ਉਪਲਬਧ ਨਹੀਂ ਸੀ, ਇਸ ਤੱਥ ਦੇ ਬਾਵਜੂਦ ਕਿ ਕਮਜ਼ੋਰੀਆਂ ਨਿਰਧਾਰਤ ਉੱਚ ਪੱਧਰ ਦਾ ਖ਼ਤਰਾ ਅਤੇ ਇੱਕ ਐਕਸਪਲਾਈਟ ਦਾ ਇੱਕ ਕਾਰਜਸ਼ੀਲ ਪ੍ਰੋਟੋਟਾਈਪ ਜੋ memcpy() ਅਤੇ memmove() ਫੰਕਸ਼ਨਾਂ ਵਿੱਚ ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਫਾਰਮੈਟ ਕੀਤੇ ਡੇਟਾ ਨੂੰ ਪ੍ਰੋਸੈਸ ਕਰਦੇ ਸਮੇਂ ਕੋਡ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ। ਲਈ ਪੈਕੇਜ ਫਿਕਸ Debian и Ubuntu ਅਜੇ ਤੱਕ ਜਾਰੀ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਹੈ ਅਤੇ ਕਮਜ਼ੋਰੀ ਇਸਦੇ ਜਨਤਕ ਖੁਲਾਸੇ ਦੇ ਲਗਭਗ ਦੋ ਮਹੀਨਿਆਂ ਬਾਅਦ ਅਤੇ Glibc ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਸੂਚਨਾ ਦੇਣ ਤੋਂ ਪੰਜ ਮਹੀਨਿਆਂ ਬਾਅਦ ਵੀ ਅਣਪਛਾਤੀ ਹੈ।

ਇਹ ਕਮਜ਼ੋਰੀ ARMv7 ਲਈ memcpy() ਅਤੇ memmove() ਦੇ ਅਸੈਂਬਲੀ ਭਾਸ਼ਾ ਲਾਗੂਕਰਨ ਵਿੱਚ ਪ੍ਰਗਟ ਹੋਈ ਅਤੇ ਕਾਪੀ ਕੀਤੇ ਖੇਤਰ ਦੇ ਆਕਾਰ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਨ ਵਾਲੇ ਪੈਰਾਮੀਟਰ ਦੇ ਨਕਾਰਾਤਮਕ ਮੁੱਲਾਂ ਦੇ ਗਲਤ ਪ੍ਰਬੰਧਨ ਕਾਰਨ ਹੋਈ। ਪੈਚ ਵਿਕਾਸ ਨਾਲ ਸਮੱਸਿਆਵਾਂ ਉਦੋਂ ਸ਼ੁਰੂ ਹੋਈਆਂ ਜਦੋਂ ਕੰਪਨੀਆਂ SUSE и Red Hat ਉਨ੍ਹਾਂ ਨੇ ਆਪਣੇ ਪਲੇਟਫਾਰਮਾਂ ਨੂੰ ਇਸ ਮੁੱਦੇ ਤੋਂ ਪ੍ਰਭਾਵਿਤ ਨਹੀਂ ਹੋਣ ਦਾ ਐਲਾਨ ਕੀਤਾ, ਕਿਉਂਕਿ ਉਹ 32-ਬਿੱਟ ARMv7 ਸਿਸਟਮਾਂ ਲਈ ਨਹੀਂ ਬਣਾਉਂਦੇ, ਅਤੇ ਪੈਚ ਵਿੱਚ ਯੋਗਦਾਨ ਪਾਉਣ ਤੋਂ ਇਨਕਾਰ ਕਰ ਦਿੱਤਾ। ਬਹੁਤ ਸਾਰੇ ਏਮਬੈਡਡ ਡਿਸਟ੍ਰੀਬਿਊਸ਼ਨਾਂ ਦੇ ਡਿਵੈਲਪਰ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ Glibc ਟੀਮ 'ਤੇ ਨਿਰਭਰ ਸਨ ਅਤੇ ਪੈਚ ਵਿੱਚ ਸਰਗਰਮੀ ਨਾਲ ਯੋਗਦਾਨ ਵੀ ਨਹੀਂ ਪਾਇਆ।

ਚੋਣ ਪੈਚ ਹੁਆਵੇਈ ਨੇ ਲਗਭਗ ਤੁਰੰਤ ਸਮੱਸਿਆ ਨੂੰ ਰੋਕਣ ਲਈ ਇੱਕ ਹੱਲ ਪੇਸ਼ ਕੀਤਾ, ਅਸੈਂਬਲੀ ਨਿਰਦੇਸ਼ਾਂ ਨੂੰ ਬਦਲਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਜੋ ਦਸਤਖਤ ਕੀਤੇ ਓਪਰੇਂਡ (bge ਅਤੇ blt) ਨੂੰ ਅਣ-ਹਸਤਾਖਰਿਤ ਸਮਾਨ (blo ਅਤੇ bhs) ਨਾਲ ਸੰਭਾਲਦੇ ਹਨ। Glibc ਰੱਖ-ਰਖਾਅ ਕਰਨ ਵਾਲਿਆਂ ਨੇ ਵੱਖ-ਵੱਖ ਗਲਤੀ ਸਥਿਤੀਆਂ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ ਟੈਸਟਾਂ ਦਾ ਇੱਕ ਸੈੱਟ ਵਿਕਸਤ ਕੀਤਾ, ਜਿਸ ਤੋਂ ਬਾਅਦ ਇਹ ਸਪੱਸ਼ਟ ਹੋ ਗਿਆ ਕਿ ਹੁਆਵੇਈ ਦਾ ਪੈਚ ਅਣਉਚਿਤ ਸੀ ਅਤੇ ਸਾਰੇ ਸੰਭਵ ਇਨਪੁੱਟ ਡੇਟਾ ਸੰਜੋਗਾਂ ਨੂੰ ਸੰਭਾਲ ਨਹੀਂ ਸਕਿਆ।

ਕਿਉਂਕਿ Aurora OS ਕੋਲ ARM ਲਈ 32-ਬਿੱਟ ਬਿਲਡ ਹੈ, ਇਸ ਲਈ ਇਸਦੇ ਡਿਵੈਲਪਰਾਂ ਨੇ ਖੁਦ ਕਮਜ਼ੋਰੀ ਨੂੰ ਠੀਕ ਕਰਨ ਅਤੇ ਭਾਈਚਾਰੇ ਨੂੰ ਇੱਕ ਹੱਲ ਪੇਸ਼ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ। ਚੁਣੌਤੀ ਵੱਖ-ਵੱਖ ਇਨਪੁਟ ਆਰਗੂਮੈਂਟਾਂ ਦਾ ਲੇਖਾ-ਜੋਖਾ ਕਰਦੇ ਹੋਏ ਫੰਕਸ਼ਨ ਦੇ ਇੱਕ ਕੁਸ਼ਲ ਅਸੈਂਬਲੀ ਲਾਗੂਕਰਨ ਨੂੰ ਲਿਖਣ ਵਿੱਚ ਸੀ। ਲਾਗੂਕਰਨ ਨੂੰ ਬਿਨਾਂ ਦਸਤਖਤ ਕੀਤੇ ਨਿਰਦੇਸ਼ਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਦੁਬਾਰਾ ਲਿਖਿਆ ਗਿਆ ਸੀ। ਪੈਚ ਇਹ ਛੋਟਾ ਨਿਕਲਿਆ, ਪਰ ਮੁੱਖ ਸਮੱਸਿਆ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਸਪੀਡ ਨੂੰ ਬਣਾਈ ਰੱਖਣਾ ਅਤੇ memcpy ਅਤੇ memmove ਫੰਕਸ਼ਨਾਂ ਦੇ ਪ੍ਰਦਰਸ਼ਨ ਦੇ ਡਿਗ੍ਰੇਡੇਸ਼ਨ ਨੂੰ ਖਤਮ ਕਰਨਾ ਸੀ, ਜਦੋਂ ਕਿ ਇਨਪੁਟ ਮੁੱਲਾਂ ਦੇ ਸਾਰੇ ਸੰਜੋਗਾਂ ਨਾਲ ਅਨੁਕੂਲਤਾ ਬਣਾਈ ਰੱਖਣਾ ਸੀ।

ਜੂਨ ਦੇ ਸ਼ੁਰੂ ਵਿੱਚ, ਦੋ ਪੈਚ ਵੇਰੀਐਂਟ ਤਿਆਰ ਕੀਤੇ ਗਏ ਸਨ, ਜੋ Glibc ਮੇਨਟੇਨਰਾਂ ਦੇ ਟੈਸਟ ਫਰੇਮਵਰਕ ਅਤੇ ਔਰੋਰਾ ਦੇ ਅੰਦਰੂਨੀ ਟੈਸਟ ਸੂਟ ਨੂੰ ਪਾਸ ਕਰਦੇ ਸਨ। 3 ਜੂਨ ਨੂੰ, ਇੱਕ ਵੇਰੀਐਂਟ ਚੁਣਿਆ ਗਿਆ ਸੀ ਅਤੇ ਭੇਜਿਆ Glibc ਮੇਲਿੰਗ ਲਿਸਟ ਵਿੱਚ। ਇੱਕ ਹਫ਼ਤੇ ਵਿੱਚ
ਸੀ ਪ੍ਰਸਤਾਵਿਤ ਇੱਕ ਹੋਰ ਪੈਚ, ਜੋ ਕਿ ਪਹੁੰਚ ਵਿੱਚ ਸਮਾਨ ਹੈ, ਨੇ ਮਲਟੀਆਰਚ ਲਾਗੂਕਰਨ ਵਿੱਚ ਇੱਕ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕੀਤਾ ਜਿਸਨੂੰ ਹੁਆਵੇਈ ਨੇ ਪਹਿਲਾਂ ਠੀਕ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਸੀ। ਇਸਦੀ ਜਾਂਚ ਕਰਨ ਵਿੱਚ ਇੱਕ ਮਹੀਨਾ ਲੱਗਿਆ ਅਤੇ ਕਾਨੂੰਨੀ ਰਜਿਸਟ੍ਰੇਸ਼ਨ ਪੈਚ ਦੀ ਮਹੱਤਤਾ ਦੇ ਕਾਰਨ।
8 ਜੁਲਾਈ ਦੇ ਸੁਧਾਰ ਸਵੀਕਾਰ ਕੀਤੇ ਗਏ ਸਨ ਆਉਣ ਵਾਲੇ glibc 2.32 ਰੀਲੀਜ਼ ਦੀ ਮੁੱਖ ਸ਼ਾਖਾ ਵਿੱਚ। ਲਾਗੂਕਰਨ ਵਿੱਚ ਦੋ ਪੈਚ ਸ਼ਾਮਲ ਹਨ: первый ARMv7 ਲਈ memcpy ਦੇ ਮਲਟੀਆਰਚ ਲਾਗੂਕਰਨ ਲਈ, ਅਤੇ ਦੂਜਾ ARM ਲਈ memcpy() ਅਤੇ memmove() ਦੇ ਜਨਰਲ ਅਸੈਂਬਲੀ ਲਾਗੂਕਰਨ ਲਈ।

ਇਹ ਮੁੱਦਾ ਲੱਖਾਂ ARMv7 ਡਿਵਾਈਸਾਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ Linux ਢੁਕਵੇਂ ਅੱਪਡੇਟ ਤੋਂ ਬਿਨਾਂ, ਮਾਲਕ ਉਹਨਾਂ ਨੂੰ ਨੈੱਟਵਰਕ ਨਾਲ ਜੋੜਨ ਦਾ ਜੋਖਮ ਲੈਂਦੇ ਹਨ (ਨੈੱਟਵਰਕ-ਪਹੁੰਚਯੋਗ ਸੇਵਾਵਾਂ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨਾਂ ਜੋ ਆਕਾਰ ਪਾਬੰਦੀਆਂ ਤੋਂ ਬਿਨਾਂ ਇਨਪੁੱਟ ਡੇਟਾ ਨੂੰ ਸਵੀਕਾਰ ਕਰਦੀਆਂ ਹਨ, 'ਤੇ ਹਮਲਾ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ)। ਉਦਾਹਰਨ ਲਈ, ਖੋਜਕਰਤਾਵਾਂ ਦੁਆਰਾ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਸ਼ੋਸ਼ਣ ਜਿਨ੍ਹਾਂ ਨੇ ਕਮਜ਼ੋਰੀ ਦੀ ਖੋਜ ਕੀਤੀ ਹੈ, ਇਹ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਵਾਹਨ ਦੇ ਸੂਚਨਾ ਪ੍ਰਣਾਲੀ ਵਿੱਚ ਬਣੇ HTTP ਸਰਵਰ 'ਤੇ ਇੱਕ ਬਹੁਤ ਵੱਡੀ GET ਬੇਨਤੀ ਭੇਜ ਕੇ ਕਿਵੇਂ ਹਮਲਾ ਕਰਨਾ ਹੈ ਅਤੇ ਸਿਸਟਮ ਤੱਕ ਰੂਟ ਪਹੁੰਚ ਪ੍ਰਾਪਤ ਕਰਨੀ ਹੈ।

ਸਰੋਤ: opennet.ru