uClibc ਅਤੇ uClibc-ng ਵਿੱਚ ਇੱਕ ਕਮਜ਼ੋਰੀ ਜੋ DNS ਕੈਸ਼ ਵਿੱਚ ਡੇਟਾ ਨੂੰ ਧੋਖਾ ਦੇਣ ਦੀ ਆਗਿਆ ਦਿੰਦੀ ਹੈ

ਮਿਆਰੀ C ਲਾਇਬ੍ਰੇਰੀਆਂ uClibc ਅਤੇ uClibc-ng ਵਿੱਚ, ਬਹੁਤ ਸਾਰੇ ਏਮਬੈਡਡ ਅਤੇ ਪੋਰਟੇਬਲ ਡਿਵਾਈਸਾਂ ਵਿੱਚ ਵਰਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਇੱਕ ਕਮਜ਼ੋਰੀ ਦੀ ਪਛਾਣ ਕੀਤੀ ਗਈ ਹੈ (CVE ਨਿਰਧਾਰਤ ਨਹੀਂ ਕੀਤਾ ਗਿਆ) ਜੋ ਕਿ ਫਰਜ਼ੀ ਡੇਟਾ ਨੂੰ DNS ਕੈਸ਼ ਵਿੱਚ ਪਾਉਣ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ, ਜਿਸਦੀ ਵਰਤੋਂ IP ਐਡਰੈੱਸ ਨੂੰ ਬਦਲਣ ਲਈ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ। ਕੈਸ਼ ਵਿੱਚ ਇੱਕ ਮਨਮਾਨੀ ਡੋਮੇਨ ਦਾ ਅਤੇ ਹਮਲਾਵਰ ਦੇ ਸਰਵਰ 'ਤੇ ਡੋਮੇਨ ਲਈ ਬੇਨਤੀਆਂ ਨੂੰ ਰੀਡਾਇਰੈਕਟ ਕਰੋ।

ਇਹ ਮੁੱਦਾ ਰਾਊਟਰਾਂ, ਐਕਸੈਸ ਪੁਆਇੰਟਾਂ, ਅਤੇ ਇੰਟਰਨੈਟ ਆਫ਼ ਥਿੰਗਸ ਡਿਵਾਈਸਾਂ ਲਈ ਵੱਖ-ਵੱਖ ਲੀਨਕਸ ਫਰਮਵੇਅਰਾਂ ਦੇ ਨਾਲ-ਨਾਲ ਏਮਬੈਡਡ ਲੀਨਕਸ ਡਿਸਟਰੀਬਿਊਸ਼ਨਾਂ ਜਿਵੇਂ ਕਿ ਓਪਨਡਬਲਯੂਆਰਟੀ ਅਤੇ ਏਮਬੈਡਡ ਜੈਂਟੂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ। ਇਹ ਨੋਟ ਕੀਤਾ ਗਿਆ ਹੈ ਕਿ ਕਮਜ਼ੋਰੀ ਬਹੁਤ ਸਾਰੇ ਨਿਰਮਾਤਾਵਾਂ ਦੇ ਡਿਵਾਈਸਾਂ ਵਿੱਚ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ (ਉਦਾਹਰਨ ਲਈ, uClibc ਦੀ ਵਰਤੋਂ Linksys, Netgear ਅਤੇ Axis ਫਰਮਵੇਅਰ ਵਿੱਚ ਕੀਤੀ ਜਾਂਦੀ ਹੈ), ਪਰ ਕਿਉਂਕਿ uClibc ਅਤੇ uClibc-ng ਵਿੱਚ ਕਮਜ਼ੋਰੀ ਸਥਿਰ ਰਹਿੰਦੀ ਹੈ, ਖਾਸ ਡਿਵਾਈਸਾਂ ਅਤੇ ਨਿਰਮਾਤਾਵਾਂ ਬਾਰੇ ਵਿਸਤ੍ਰਿਤ ਜਾਣਕਾਰੀ ਜਿਨ੍ਹਾਂ ਦੇ ਉਤਪਾਦ ਸਮੱਸਿਆ ਉਪਲਬਧ ਹੈ। ਅਜੇ ਤੱਕ ਖੁਲਾਸਾ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਹੈ।

ਕਮਜ਼ੋਰੀ DNS ਪੁੱਛਗਿੱਛਾਂ ਨੂੰ ਭੇਜਣ ਲਈ ਕੋਡ ਵਿੱਚ ਅਨੁਮਾਨਿਤ ਲੈਣ-ਦੇਣ ਪਛਾਣਕਰਤਾਵਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਹੈ। DNS ਬੇਨਤੀ ਦੀ ਪਛਾਣ ਨੰਬਰ ਨੂੰ ਪੋਰਟ ਨੰਬਰਾਂ ਦੇ ਵਾਧੂ ਬੇਤਰਤੀਬੇ ਦੀ ਵਰਤੋਂ ਕੀਤੇ ਬਿਨਾਂ ਕਾਊਂਟਰ ਨੂੰ ਵਧਾ ਕੇ ਚੁਣਿਆ ਗਿਆ ਸੀ, ਜਿਸ ਨਾਲ ਜਾਅਲੀ ਜਵਾਬਾਂ ਦੇ ਨਾਲ UDP ਪੈਕੇਟਾਂ ਦੀ ਅਗਾਊਂ ਭੇਜਣ ਦੁਆਰਾ DNS ਕੈਸ਼ ਨੂੰ ਜ਼ਹਿਰੀਲਾ ਕਰਨਾ ਸੰਭਵ ਹੋ ਗਿਆ ਸੀ (ਜਵਾਬ ਸਵੀਕਾਰ ਕੀਤਾ ਜਾਵੇਗਾ ਜੇਕਰ ਇਹ ਪਹਿਲਾਂ ਪਹੁੰਚਦਾ ਹੈ ਅਸਲ ਸਰਵਰ ਤੋਂ ਜਵਾਬ ਅਤੇ ਸਹੀ ID ਸ਼ਾਮਲ ਕਰਦਾ ਹੈ)। 2008 ਵਿੱਚ ਪ੍ਰਸਤਾਵਿਤ ਕਾਮਿੰਸਕੀ ਵਿਧੀ ਦੇ ਉਲਟ, ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਪਛਾਣਕਰਤਾ ਦਾ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣ ਦੀ ਵੀ ਲੋੜ ਨਹੀਂ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਸ਼ੁਰੂਆਤੀ ਤੌਰ 'ਤੇ ਅਨੁਮਾਨ ਲਗਾਉਣ ਯੋਗ ਹੈ (ਮੁੱਲ ਸ਼ੁਰੂ ਵਿੱਚ 1 'ਤੇ ਸੈੱਟ ਕੀਤਾ ਗਿਆ ਹੈ, ਜੋ ਕਿ ਹਰ ਬੇਨਤੀ ਨਾਲ ਵਧਾਇਆ ਜਾਂਦਾ ਹੈ, ਨਾ ਕਿ ਬੇਤਰਤੀਬ ਢੰਗ ਨਾਲ ਚੁਣਿਆ ਗਿਆ)।

ਆਈਡੈਂਟੀਫਾਇਰ ਬਰੂਟ ਫੋਰਸ ਤੋਂ ਬਚਾਉਣ ਲਈ, ਸਪੈਸੀਫਿਕੇਸ਼ਨ ਵਾਧੂ ਸਰੋਤ ਨੈਟਵਰਕ ਪੋਰਟਾਂ ਦੀ ਇੱਕ ਬੇਤਰਤੀਬ ਵੰਡ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਸਿਫਾਰਸ਼ ਕਰਦਾ ਹੈ ਜਿੱਥੋਂ DNS ਬੇਨਤੀਆਂ ਭੇਜੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਜੋ ਪਛਾਣਕਰਤਾ ਦੇ ਨਾਕਾਫ਼ੀ ਵੱਡੇ ਆਕਾਰ ਲਈ ਮੁਆਵਜ਼ਾ ਦਿੰਦੀਆਂ ਹਨ। ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ ਜਾਅਲੀ ਜਵਾਬ ਬਣਾਉਣ ਲਈ ਪੋਰਟ ਰੈਂਡਮਾਈਜ਼ੇਸ਼ਨ ਨੂੰ ਸਮਰੱਥ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਇੱਕ 16-ਬਿੱਟ ਪਛਾਣਕਰਤਾ ਦੀ ਚੋਣ ਕਰਨ ਤੋਂ ਇਲਾਵਾ, ਤੁਹਾਨੂੰ ਨੈੱਟਵਰਕ ਪੋਰਟ ਨੰਬਰ ਵੀ ਚੁਣਨਾ ਚਾਹੀਦਾ ਹੈ। uClibc ਅਤੇ uClibc-ng ਵਿੱਚ, ਅਜਿਹੇ ਰੈਂਡਮਾਈਜ਼ੇਸ਼ਨ ਨੂੰ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਸਮਰੱਥ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਸੀ (ਜਦੋਂ ਬਾਈਂਡ ਨੂੰ ਕਾਲ ਕਰਦੇ ਹੋ, ਇੱਕ ਬੇਤਰਤੀਬ ਸਰੋਤ UDP ਪੋਰਟ ਨਿਰਧਾਰਤ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਸੀ) ਅਤੇ ਇਸਦੀ ਵਰਤੋਂ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਸੈਟਿੰਗਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ।

ਜਦੋਂ ਪੋਟ ਰੈਂਡਮਾਈਜ਼ੇਸ਼ਨ ਅਸਮਰੱਥ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਵਧੀ ਹੋਈ ਬੇਨਤੀ ਆਈਡੀ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਨਾ ਇੱਕ ਮਾਮੂਲੀ ਕੰਮ ਵਜੋਂ ਚਿੰਨ੍ਹਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਪਰ ਭਾਵੇਂ ਰੈਂਡਮਾਈਜੇਸ਼ਨ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਹਮਲਾਵਰ ਨੂੰ ਸਿਰਫ 32768–60999 ਰੇਂਜ ਤੋਂ ਨੈਟਵਰਕ ਪੋਰਟ ਦਾ ਅਨੁਮਾਨ ਲਗਾਉਣ ਦੀ ਜ਼ਰੂਰਤ ਹੁੰਦੀ ਹੈ, ਜਿਸ ਲਈ ਉਹ ਵੱਖ-ਵੱਖ ਨੈਟਵਰਕ ਪੋਰਟਾਂ ਤੇ ਫਰਜ਼ੀ ਜਵਾਬਾਂ ਦੇ ਵੱਡੇ ਸਮਕਾਲੀ ਭੇਜਣ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹਨ।

uClibc ਅਤੇ uClibc-ng ਦੀਆਂ ਸਾਰੀਆਂ ਮੌਜੂਦਾ ਰੀਲੀਜ਼ਾਂ ਵਿੱਚ ਸਮੱਸਿਆ ਦੀ ਪੁਸ਼ਟੀ ਕੀਤੀ ਗਈ ਹੈ, ਜਿਸ ਵਿੱਚ uClibc 0.9.33.2 ਅਤੇ uClibc-ng 1.0.40 ਦੇ ਸਭ ਤੋਂ ਤਾਜ਼ਾ ਸੰਸਕਰਣ ਸ਼ਾਮਲ ਹਨ। ਸਤੰਬਰ 2021 ਵਿੱਚ, ਫਿਕਸਾਂ ਦੀ ਤਾਲਮੇਲ ਤਿਆਰ ਕਰਨ ਲਈ ਕਮਜ਼ੋਰੀ ਬਾਰੇ ਜਾਣਕਾਰੀ CERT/CC ਨੂੰ ਭੇਜੀ ਗਈ ਸੀ। ਜਨਵਰੀ 2022 ਵਿੱਚ, ਸਮੱਸਿਆ ਬਾਰੇ ਡੇਟਾ CERT/CC ਨਾਲ ਸਹਿਯੋਗ ਕਰਨ ਵਾਲੇ 200 ਤੋਂ ਵੱਧ ਨਿਰਮਾਤਾਵਾਂ ਨਾਲ ਸਾਂਝਾ ਕੀਤਾ ਗਿਆ ਸੀ। ਮਾਰਚ ਵਿੱਚ, uClibc-ng ਪ੍ਰੋਜੈਕਟ ਦੇ ਰੱਖ-ਰਖਾਅ ਕਰਨ ਵਾਲੇ ਨਾਲ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਸੰਪਰਕ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਗਈ ਸੀ, ਪਰ ਉਸਨੇ ਜਵਾਬ ਦਿੱਤਾ ਕਿ ਉਹ ਆਪਣੇ ਆਪ ਕਮਜ਼ੋਰੀ ਨੂੰ ਠੀਕ ਕਰਨ ਦੇ ਯੋਗ ਨਹੀਂ ਸੀ ਅਤੇ ਸਮੱਸਿਆ ਬਾਰੇ ਜਨਤਕ ਤੌਰ 'ਤੇ ਜਾਣਕਾਰੀ ਦਾ ਖੁਲਾਸਾ ਕਰਨ ਦੀ ਸਿਫ਼ਾਰਸ਼ ਕੀਤੀ, ਇੱਕ ਵਿਕਾਸ ਵਿੱਚ ਮਦਦ ਪ੍ਰਾਪਤ ਕਰਨ ਦੀ ਉਮੀਦ ਵਿੱਚ। ਭਾਈਚਾਰੇ ਤੋਂ ਠੀਕ ਕਰੋ। ਨਿਰਮਾਤਾਵਾਂ ਵਿੱਚ, NETGEAR ਨੇ ਇੱਕ ਅਪਡੇਟ ਜਾਰੀ ਕਰਨ ਦੀ ਘੋਸ਼ਣਾ ਕੀਤੀ ਜੋ ਕਮਜ਼ੋਰੀ ਨੂੰ ਖਤਮ ਕਰਦਾ ਹੈ।

ਸਰੋਤ: opennet.ru