TL; ਡਾ. ਇਸ ਲੇਖ ਵਿੱਚ, ਅਸੀਂ ਸਖ਼ਤ ਕਰਨ ਵਾਲੀਆਂ ਸਕੀਮਾਂ ਦੀ ਪੜਚੋਲ ਕਰਦੇ ਹਾਂ ਜੋ ਪੰਜ ਪ੍ਰਸਿੱਧ ਲੀਨਕਸ ਡਿਸਟਰੀਬਿਊਸ਼ਨਾਂ 'ਤੇ ਬਾਕਸ ਤੋਂ ਬਾਹਰ ਕੰਮ ਕਰਦੀਆਂ ਹਨ। ਹਰੇਕ ਲਈ, ਅਸੀਂ ਡਿਫਾਲਟ ਕਰਨਲ ਸੰਰਚਨਾ ਲਈ, ਸਾਰੇ ਪੈਕੇਜ ਲੋਡ ਕੀਤੇ, ਅਤੇ ਨੱਥੀ ਬਾਈਨਰੀਆਂ ਵਿੱਚ ਸੁਰੱਖਿਆ ਸਕੀਮਾਂ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕੀਤਾ। ਵਿਚਾਰੇ ਗਏ ਵੰਡਾਂ ਹਨ ਓਪਨਸੂਸੇ 12.4, ਡੇਬੀਅਨ 9, ਸੈਂਟੋਸ, RHEL 6.10 ਅਤੇ 7, ਨਾਲ ਹੀ ਉਬੰਟੂ 14.04, 12.04 ਅਤੇ 18.04 LTS।

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

ਸਮੀਖਿਆ ਨੇ ਦਿਖਾਇਆ ਕਿ ਸਭ ਤੋਂ ਵੱਧ ਸੁਰੱਖਿਆ ਵਿਧੀਆਂ ਉਬੰਟੂ 18.04 ਵਿੱਚ OS ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਪੱਧਰਾਂ 'ਤੇ ਲਾਗੂ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ, ਜਿਸ ਤੋਂ ਬਾਅਦ ਡੇਬੀਅਨ 9 ਹੈ। ਦੂਜੇ ਪਾਸੇ, OpenSUSE 12.4, CentOS 7 ਅਤੇ RHEL 7 ਵੀ ਬੁਨਿਆਦੀ ਸੁਰੱਖਿਆ ਸਕੀਮਾਂ ਨੂੰ ਲਾਗੂ ਕਰਦੇ ਹਨ, ਅਤੇ ਸਟੈਕ ਟੱਕਰ ਸੁਰੱਖਿਆ। ਡਿਫਾਲਟ ਪੈਕੇਜਾਂ ਦੇ ਬਹੁਤ ਸੰਘਣੇ ਸੈੱਟ ਨਾਲ ਹੋਰ ਵੀ ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ।

ਜਾਣ ਪਛਾਣ

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

ਇਹ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਪ੍ਰੋਗਰਾਮਾਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰਨ ਜਾਂ ਸਖ਼ਤ ਕਰਨ ਦੇ ਤਰੀਕੇ ਲਾਗੂ ਹੁੰਦੇ ਹਨ। ਅਸੀਂ ਕੁਝ ਕਿਸਮਾਂ ਦੀਆਂ ਗਲਤੀਆਂ ਨੂੰ ਰੋਕ ਨਹੀਂ ਸਕਦੇ, ਪਰ ਅਸੀਂ ਹਮਲਾਵਰ ਦੀ ਜ਼ਿੰਦਗੀ ਨੂੰ ਹੋਰ ਮੁਸ਼ਕਲ ਬਣਾ ਸਕਦੇ ਹਾਂ ਅਤੇ ਰੋਕ ਕੇ ਜਾਂ ਰੋਕ ਕੇ ਸਮੱਸਿਆ ਨੂੰ ਅੰਸ਼ਕ ਤੌਰ 'ਤੇ ਹੱਲ ਕਰ ਸਕਦੇ ਹਾਂ। ਸ਼ੋਸ਼ਣ ਇਹ ਗਲਤੀਆਂ. ਅਜਿਹੀ ਸੁਰੱਖਿਆ ਦੀ ਵਰਤੋਂ ਸਾਰੇ ਆਧੁਨਿਕ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮਾਂ ਵਿੱਚ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਪਰ ਵਿਧੀਆਂ ਜਟਿਲਤਾ, ਕੁਸ਼ਲਤਾ ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ ਵਿੱਚ ਬਹੁਤ ਭਿੰਨ ਹਨ: ਸਟੈਕ ਕੈਨਰੀਜ਼ ਅਤੇ ASLR ਪੂਰੀ ਸੁਰੱਖਿਆ ਲਈ ਸੀ.ਆਈ.ਆਈ. и ਰੋਪ. ਇਸ ਲੇਖ ਵਿੱਚ, ਅਸੀਂ ਦੇਖਾਂਗੇ ਕਿ ਡਿਫਾਲਟ ਸੰਰਚਨਾ ਵਿੱਚ ਸਭ ਤੋਂ ਪ੍ਰਸਿੱਧ ਲੀਨਕਸ ਡਿਸਟਰੀਬਿਊਸ਼ਨਾਂ ਵਿੱਚ ਕਿਹੜੀਆਂ ਸੁਰੱਖਿਆ ਵਿਧੀਆਂ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਹਰੇਕ ਵੰਡ ਦੇ ਪੈਕੇਜ ਪ੍ਰਬੰਧਨ ਪ੍ਰਣਾਲੀਆਂ ਦੁਆਰਾ ਵੰਡੀਆਂ ਗਈਆਂ ਬਾਈਨਰੀਆਂ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੀ ਵੀ ਜਾਂਚ ਕਰਾਂਗੇ।

CVE ਅਤੇ ਸੁਰੱਖਿਆ

ਅਸੀਂ ਸਾਰੇ "ਸਾਲ ਦੀਆਂ ਸਭ ਤੋਂ ਕਮਜ਼ੋਰ ਐਪਲੀਕੇਸ਼ਨਾਂ" ਜਾਂ "ਸਭ ਤੋਂ ਕਮਜ਼ੋਰ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ" ਵਰਗੇ ਸਿਰਲੇਖਾਂ ਵਾਲੇ ਲੇਖ ਦੇਖੇ ਹਨ। ਆਮ ਤੌਰ 'ਤੇ ਉਹ ਕਮਜ਼ੋਰੀਆਂ ਬਾਰੇ ਰਿਕਾਰਡਾਂ ਦੀ ਕੁੱਲ ਗਿਣਤੀ 'ਤੇ ਅੰਕੜੇ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ CVE (ਆਮ ਕਮਜ਼ੋਰੀ ਅਤੇ ਐਕਸਪੋਜ਼ਰ), ਤੋਂ ਪ੍ਰਾਪਤ ਕੀਤਾ ਰਾਸ਼ਟਰੀ ਕਮਜ਼ੋਰੀ ਡੇਟਾਬੇਸ (NVD) ਤੱਕ ਐਨਆਈਐਸਟੀ ਅਤੇ ਹੋਰ ਸਰੋਤ। ਇਸ ਤੋਂ ਬਾਅਦ, ਇਹਨਾਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਜਾਂ OS ਨੂੰ CVE ਦੀ ਸੰਖਿਆ ਦੁਆਰਾ ਦਰਜਾ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। ਬਦਕਿਸਮਤੀ ਨਾਲ, ਜਦੋਂ ਕਿ CVE ਮੁੱਦਿਆਂ ਨੂੰ ਟਰੈਕ ਕਰਨ ਅਤੇ ਵਿਕਰੇਤਾਵਾਂ ਅਤੇ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਸੂਚਿਤ ਕਰਨ ਲਈ ਬਹੁਤ ਉਪਯੋਗੀ ਹਨ, ਉਹ ਸਾਫਟਵੇਅਰ ਦੀ ਅਸਲ ਸੁਰੱਖਿਆ ਬਾਰੇ ਬਹੁਤ ਘੱਟ ਕਹਿੰਦੇ ਹਨ।

ਇੱਕ ਉਦਾਹਰਨ ਦੇ ਤੌਰ 'ਤੇ, ਲੀਨਕਸ ਕਰਨਲ ਲਈ ਪਿਛਲੇ ਚਾਰ ਸਾਲਾਂ ਵਿੱਚ CVE ਦੀ ਕੁੱਲ ਸੰਖਿਆ ਅਤੇ ਪੰਜ ਸਭ ਤੋਂ ਪ੍ਰਸਿੱਧ ਸਰਵਰ ਡਿਸਟਰੀਬਿਊਸ਼ਨਾਂ, ਜਿਵੇਂ ਕਿ ਉਬੰਟੂ, ਡੇਬੀਅਨ, Red Hat Enterprise Linux ਅਤੇ OpenSUSE 'ਤੇ ਵਿਚਾਰ ਕਰੋ।

ਅੰਜੀਰ. 1

ਇਹ ਗ੍ਰਾਫ ਸਾਨੂੰ ਕੀ ਦੱਸਦਾ ਹੈ? ਕੀ CVE ਦੀ ਵੱਧ ਗਿਣਤੀ ਦਾ ਮਤਲਬ ਇਹ ਹੈ ਕਿ ਇੱਕ ਵੰਡ ਦੂਜੀ ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਕਮਜ਼ੋਰ ਹੈ? ਕੋਈ ਉੱਤਰ ਨਹੀਂ. ਉਦਾਹਰਨ ਲਈ, ਇਸ ਲੇਖ ਵਿੱਚ ਤੁਸੀਂ ਦੇਖੋਗੇ ਕਿ ਡੇਬੀਅਨ ਕੋਲ ਓਪਨਸੂਸੇ ਜਾਂ ਰੈੱਡਹੈਟ ਲੀਨਕਸ ਦੀ ਤੁਲਨਾ ਵਿੱਚ ਮਜ਼ਬੂਤ ​​ਸੁਰੱਖਿਆ ਵਿਧੀਆਂ ਹਨ, ਅਤੇ ਫਿਰ ਵੀ ਡੇਬੀਅਨ ਵਿੱਚ ਵਧੇਰੇ CVE ਹਨ। ਹਾਲਾਂਕਿ, ਇਹ ਜ਼ਰੂਰੀ ਤੌਰ 'ਤੇ ਕਮਜ਼ੋਰ ਸੁਰੱਖਿਆ ਦਾ ਮਤਲਬ ਨਹੀਂ ਹੈ: ਇੱਥੋਂ ਤੱਕ ਕਿ ਇੱਕ CVE ਦੀ ਮੌਜੂਦਗੀ ਇਹ ਨਹੀਂ ਦਰਸਾਉਂਦੀ ਹੈ ਕਿ ਕੀ ਇੱਕ ਕਮਜ਼ੋਰੀ ਹੈ ਸ਼ੋਸ਼ਣ ਕੀਤਾ. ਗੰਭੀਰਤਾ ਸਕੋਰ ਇਸ ਗੱਲ ਦਾ ਸੰਕੇਤ ਦਿੰਦੇ ਹਨ ਕਿ ਕਿਵੇਂ ਸ਼ਾਇਦ ਇੱਕ ਕਮਜ਼ੋਰੀ ਦਾ ਸ਼ੋਸ਼ਣ, ਪਰ ਅੰਤ ਵਿੱਚ ਸ਼ੋਸ਼ਣ ਪ੍ਰਭਾਵਿਤ ਪ੍ਰਣਾਲੀਆਂ ਵਿੱਚ ਮੌਜੂਦ ਸੁਰੱਖਿਆ ਅਤੇ ਹਮਲਾਵਰਾਂ ਦੇ ਸਰੋਤਾਂ ਅਤੇ ਸਮਰੱਥਾਵਾਂ 'ਤੇ ਬਹੁਤ ਜ਼ਿਆਦਾ ਨਿਰਭਰ ਕਰਦਾ ਹੈ। ਇਸ ਤੋਂ ਇਲਾਵਾ, CVE ਰਿਪੋਰਟਾਂ ਦੀ ਅਣਹੋਂਦ ਦੂਜਿਆਂ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦੀ ਅਣਰਜਿਸਟਰਡ ਜਾਂ ਅਣਜਾਣ ਕਮਜ਼ੋਰੀਆਂ CVE ਵਿੱਚ ਅੰਤਰ ਸਾਫਟਵੇਅਰ ਗੁਣਵੱਤਾ ਤੋਂ ਇਲਾਵਾ ਹੋਰ ਕਾਰਕਾਂ ਕਰਕੇ ਹੋ ਸਕਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਟੈਸਟਿੰਗ ਲਈ ਨਿਰਧਾਰਤ ਸਰੋਤ ਜਾਂ ਉਪਭੋਗਤਾ ਅਧਾਰ ਦਾ ਆਕਾਰ ਸ਼ਾਮਲ ਹੈ। ਸਾਡੀ ਉਦਾਹਰਨ ਵਿੱਚ, ਡੇਬੀਅਨ ਦੀ CVE ਦੀ ਵੱਧ ਗਿਣਤੀ ਸਿਰਫ਼ ਇਹ ਸੰਕੇਤ ਦੇ ਸਕਦੀ ਹੈ ਕਿ ਡੇਬੀਅਨ ਹੋਰ ਸੌਫਟਵੇਅਰ ਪੈਕੇਜ ਭੇਜਦਾ ਹੈ।

ਬੇਸ਼ੱਕ, CVE ਸਿਸਟਮ ਉਪਯੋਗੀ ਜਾਣਕਾਰੀ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਉਚਿਤ ਸੁਰੱਖਿਆ ਬਣਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। ਅਸੀਂ ਪ੍ਰੋਗਰਾਮ ਦੀ ਅਸਫਲਤਾ ਦੇ ਕਾਰਨਾਂ ਨੂੰ ਜਿੰਨਾ ਬਿਹਤਰ ਸਮਝਦੇ ਹਾਂ, ਸ਼ੋਸ਼ਣ ਦੇ ਸੰਭਾਵਿਤ ਤਰੀਕਿਆਂ ਦੀ ਪਛਾਣ ਕਰਨਾ ਅਤੇ ਉਚਿਤ ਵਿਧੀਆਂ ਵਿਕਸਿਤ ਕਰਨਾ ਓਨਾ ਹੀ ਆਸਾਨ ਹੁੰਦਾ ਹੈ। ਖੋਜ ਅਤੇ ਜਵਾਬ. ਚਿੱਤਰ ਵਿੱਚ. 2 ਪਿਛਲੇ ਚਾਰ ਸਾਲਾਂ ਵਿੱਚ ਸਾਰੀਆਂ ਵੰਡਾਂ ਲਈ ਕਮਜ਼ੋਰੀਆਂ ਦੀਆਂ ਸ਼੍ਰੇਣੀਆਂ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ (ਸਰੋਤ). ਇਹ ਤੁਰੰਤ ਸਪੱਸ਼ਟ ਹੈ ਕਿ ਜ਼ਿਆਦਾਤਰ CVE ਹੇਠ ਲਿਖੀਆਂ ਸ਼੍ਰੇਣੀਆਂ ਵਿੱਚ ਆਉਂਦੇ ਹਨ: ਸੇਵਾ ਤੋਂ ਇਨਕਾਰ (DoS), ਕੋਡ ਐਗਜ਼ੀਕਿਊਸ਼ਨ, ਓਵਰਫਲੋ, ਮੈਮੋਰੀ ਭ੍ਰਿਸ਼ਟਾਚਾਰ, ਜਾਣਕਾਰੀ ਲੀਕੇਜ (ਐਕਸਫਿਲਟਰੇਸ਼ਨ) ਅਤੇ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਵਾਧਾ। ਹਾਲਾਂਕਿ ਕਈ CVE ਨੂੰ ਵੱਖ-ਵੱਖ ਸ਼੍ਰੇਣੀਆਂ ਵਿੱਚ ਕਈ ਵਾਰ ਗਿਣਿਆ ਜਾਂਦਾ ਹੈ, ਆਮ ਤੌਰ 'ਤੇ ਉਹੀ ਮੁੱਦੇ ਸਾਲ ਦਰ ਸਾਲ ਜਾਰੀ ਰਹਿੰਦੇ ਹਨ। ਲੇਖ ਦੇ ਅਗਲੇ ਹਿੱਸੇ ਵਿੱਚ, ਅਸੀਂ ਇਹਨਾਂ ਕਮਜ਼ੋਰੀਆਂ ਦੇ ਸ਼ੋਸ਼ਣ ਨੂੰ ਰੋਕਣ ਲਈ ਵੱਖ-ਵੱਖ ਸੁਰੱਖਿਆ ਯੋਜਨਾਵਾਂ ਦੀ ਵਰਤੋਂ ਦਾ ਮੁਲਾਂਕਣ ਕਰਾਂਗੇ।

ਅੰਜੀਰ. 2

ਕੰਮ

ਇਸ ਲੇਖ ਵਿਚ ਅਸੀਂ ਹੇਠਾਂ ਦਿੱਤੇ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦੇਣ ਦਾ ਇਰਾਦਾ ਰੱਖਦੇ ਹਾਂ:

• ਵੱਖ-ਵੱਖ ਲੀਨਕਸ ਡਿਸਟਰੀਬਿਊਸ਼ਨਾਂ ਦੀ ਸੁਰੱਖਿਆ ਕੀ ਹੈ? ਕਰਨਲ ਅਤੇ ਯੂਜ਼ਰ ਸਪੇਸ ਐਪਲੀਕੇਸ਼ਨਾਂ ਵਿੱਚ ਕਿਹੜੀ ਸੁਰੱਖਿਆ ਵਿਧੀ ਮੌਜੂਦ ਹੈ?
• ਡਿਸਟ੍ਰੀਬਿਊਸ਼ਨਾਂ ਵਿੱਚ ਸਮੇਂ ਦੇ ਨਾਲ ਸੁਰੱਖਿਆ ਵਿਧੀਆਂ ਨੂੰ ਕਿਵੇਂ ਅਪਣਾਇਆ ਗਿਆ ਹੈ?
• ਹਰੇਕ ਵੰਡ ਲਈ ਪੈਕੇਜਾਂ ਅਤੇ ਲਾਇਬ੍ਰੇਰੀਆਂ ਦੀ ਔਸਤ ਨਿਰਭਰਤਾ ਕੀ ਹੈ?
• ਹਰੇਕ ਬਾਈਨਰੀ ਲਈ ਕਿਹੜੀਆਂ ਸੁਰੱਖਿਆਵਾਂ ਲਾਗੂ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ?

ਵੰਡਾਂ ਦੀ ਚੋਣ

ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ ਵੰਡ ਸਥਾਪਨਾਵਾਂ 'ਤੇ ਸਹੀ ਅੰਕੜੇ ਲੱਭਣਾ ਮੁਸ਼ਕਲ ਹੈ, ਕਿਉਂਕਿ ਜ਼ਿਆਦਾਤਰ ਮਾਮਲਿਆਂ ਵਿੱਚ ਡਾਉਨਲੋਡਸ ਦੀ ਸੰਖਿਆ ਅਸਲ ਸਥਾਪਨਾਵਾਂ ਦੀ ਸੰਖਿਆ ਨਹੀਂ ਦਰਸਾਉਂਦੀ ਹੈ। ਹਾਲਾਂਕਿ, ਯੂਨਿਕਸ ਵੇਰੀਐਂਟ ਜ਼ਿਆਦਾਤਰ ਸਰਵਰ ਸਿਸਟਮ ਬਣਾਉਂਦੇ ਹਨ (ਵੈੱਬ ਸਰਵਰਾਂ 'ਤੇ 69,2%, ਦੁਆਰਾ ਅੰਕੜੇ W3techs ਅਤੇ ਹੋਰ ਸਰੋਤ), ਅਤੇ ਉਹਨਾਂ ਦਾ ਹਿੱਸਾ ਲਗਾਤਾਰ ਵਧ ਰਿਹਾ ਹੈ। ਇਸ ਤਰ੍ਹਾਂ, ਸਾਡੀ ਖੋਜ ਲਈ ਅਸੀਂ ਪਲੇਟਫਾਰਮ 'ਤੇ ਬਕਸੇ ਤੋਂ ਬਾਹਰ ਉਪਲਬਧ ਵੰਡਾਂ 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਿਤ ਕੀਤਾ ਗੂਗਲ ਕ੍ਲਾਉਡ. ਖਾਸ ਤੌਰ 'ਤੇ, ਅਸੀਂ ਹੇਠਾਂ ਦਿੱਤੇ OS ਨੂੰ ਚੁਣਿਆ ਹੈ:

ਵੰਡ/ਵਰਜਨ
ਕੋਰ
ਬਣਾਓ

ਓਪਨਸੂਸੇ ਐਕਸਐਨਯੂਐਮਐਕਸ
4.12.14-95.3-ਪੂਰਵ-ਨਿਰਧਾਰਤ
#1 SMP ਬੁਧ 5 ਦਸੰਬਰ 06:00:48 UTC 2018 (63a8d29)

ਡੇਬੀਅਨ 9 (ਖਿੱਚ)
4.9.0-8-amd64
#1 SMP ਡੇਬੀਅਨ 4.9.130-2 (2018-10-27)

CentOS 6.10
2.6.32-754.10.1.el6.x86_64
#1 SMP ਮੰਗਲਵਾਰ 15 ਜਨਵਰੀ 17:07:28 UTC 2019

CentOS 7
3.10.0-957.5.1.el7.x86_64
#1 SMP ਸ਼ੁੱਕਰਵਾਰ 1 ਫਰਵਰੀ 14:54:57 UTC 2019

Red Hat Enterprise Linux ਸਰਵਰ 6.10 (ਸੈਂਟੀਆਗੋ)
2.6.32-754.9.1.el6.x86_64
#1 SMP ਬੁਧ 21 ਨਵੰਬਰ 15:08:21 EST 2018

Red Hat Enterprise Linux ਸਰਵਰ 7.6 (Maipo)
3.10.0-957.1.3.el7.x86_64
#1 SMP ਵੀਰਵਾਰ 15 ਨਵੰਬਰ 17:36:42 UTC 2018

ਉਬੰਟੂ 14.04 (ਭਰੋਸੇਯੋਗ ਤਾਹਰ)
4.4.0–140-ਆਮ

#166~14.04.1-Ubuntu SMP ਸ਼ਨੀਵਾਰ 17 ਨਵੰਬਰ 01:52:43 UTC 20…

Ubuntu 16.04 (Xenial Xerus)
4.15.0–1026-gcp
#27~16.04.1-ਉਬੰਟੂ SMP ਸ਼ੁਕਰਵਾਰ 7 ਦਸੰਬਰ 09:59:47 UTC 2018

ਉਬੰਟੂ 18.04 (ਬਾਇਓਨਿਕ ਬੀਵਰ)
4.15.0–1026-gcp
#27-ਉਬੰਟੂ ਐਸਐਮਪੀ ਵੀਰਵਾਰ 6 ਦਸੰਬਰ 18:27:01 ਯੂਟੀਸੀ 2018

ਟੇਬਲ 1

ਐਨਾਲਜ਼

ਆਉ ਡਿਫਾਲਟ ਕਰਨਲ ਸੰਰਚਨਾ ਦਾ ਅਧਿਐਨ ਕਰੀਏ, ਨਾਲ ਹੀ ਹਰੇਕ ਡਿਸਟਰੀਬਿਊਸ਼ਨ ਦੇ ਪੈਕੇਜ ਮੈਨੇਜਰ ਦੁਆਰਾ ਉਪਲੱਬਧ ਪੈਕੇਜਾਂ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦਾ ਬਾਕਸ ਤੋਂ ਬਾਹਰ। ਇਸ ਤਰ੍ਹਾਂ, ਅਸੀਂ ਅਸਥਿਰ ਰਿਪੋਜ਼ਟਰੀਆਂ (ਜਿਵੇਂ ਕਿ ਡੇਬੀਅਨ 'ਟੈਸਟਿੰਗ' ਮਿਰਰ) ਅਤੇ ਥਰਡ-ਪਾਰਟੀ ਪੈਕੇਜਾਂ (ਜਿਵੇਂ ਕਿ ਸਟੈਂਡਰਡ ਮਿਰਰਾਂ ਤੋਂ ਐਨਵੀਡੀਆ ਪੈਕੇਜ) ਤੋਂ ਪੈਕੇਜਾਂ ਨੂੰ ਅਣਡਿੱਠ ਕਰਦੇ ਹੋਏ, ਹਰੇਕ ਡਿਸਟ੍ਰੀਬਿਊਸ਼ਨ ਦੇ ਡਿਫੌਲਟ ਮਿਰਰਾਂ ਤੋਂ ਪੈਕੇਜਾਂ 'ਤੇ ਵਿਚਾਰ ਕਰਦੇ ਹਾਂ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਅਸੀਂ ਕਸਟਮ ਕਰਨਲ ਸੰਕਲਨ ਜਾਂ ਸੁਰੱਖਿਆ-ਸਖਤ ਸੰਰਚਨਾਵਾਂ 'ਤੇ ਵਿਚਾਰ ਨਹੀਂ ਕਰਦੇ ਹਾਂ।

ਕਰਨਲ ਸੰਰਚਨਾ ਵਿਸ਼ਲੇਸ਼ਣ

ਅਸੀਂ ਦੇ ਅਧਾਰ ਤੇ ਇੱਕ ਵਿਸ਼ਲੇਸ਼ਣ ਸਕ੍ਰਿਪਟ ਲਾਗੂ ਕੀਤੀ ਮੁਫ਼ਤ kconfig ਚੈਕਰ. ਆਉ ਨਾਮਿਤ ਡਿਸਟਰੀਬਿਊਸ਼ਨਾਂ ਦੇ ਆਊਟ-ਆਫ-ਦ-ਬਾਕਸ ਸੁਰੱਖਿਆ ਮਾਪਦੰਡਾਂ ਨੂੰ ਵੇਖੀਏ ਅਤੇ ਇਹਨਾਂ ਦੀ ਸੂਚੀ ਨਾਲ ਤੁਲਨਾ ਕਰੀਏ ਕੋਰ ਸਵੈ ਰੱਖਿਆ ਪ੍ਰੋਜੈਕਟ (KSPP)। ਹਰੇਕ ਸੰਰਚਨਾ ਵਿਕਲਪ ਲਈ, ਸਾਰਣੀ 2 ਲੋੜੀਂਦੀ ਸੈਟਿੰਗ ਦਾ ਵਰਣਨ ਕਰਦੀ ਹੈ: ਚੈੱਕਬਾਕਸ ਉਹਨਾਂ ਵੰਡਾਂ ਲਈ ਹੈ ਜੋ KSSP ਸਿਫ਼ਾਰਿਸ਼ਾਂ ਦੀ ਪਾਲਣਾ ਕਰਦੇ ਹਨ (ਸ਼ਰਤਾਂ ਦੀ ਵਿਆਖਿਆ ਲਈ ਹੇਠਾਂ ਦੇਖੋ)। ਇੱਥੇ; ਭਵਿੱਖ ਦੇ ਲੇਖਾਂ ਵਿੱਚ ਅਸੀਂ ਦੱਸਾਂਗੇ ਕਿ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕਿੰਨੀਆਂ ਸੁਰੱਖਿਆ ਵਿਧੀਆਂ ਹੋਂਦ ਵਿੱਚ ਆਈਆਂ ਅਤੇ ਉਹਨਾਂ ਦੀ ਗੈਰਹਾਜ਼ਰੀ ਵਿੱਚ ਇੱਕ ਸਿਸਟਮ ਨੂੰ ਕਿਵੇਂ ਹੈਕ ਕਰਨਾ ਹੈ)।

ਆਮ ਤੌਰ 'ਤੇ, ਨਵੇਂ ਕਰਨਲ ਵਿੱਚ ਬਾਕਸ ਤੋਂ ਬਾਹਰ ਸਖਤ ਸੈਟਿੰਗਾਂ ਹੁੰਦੀਆਂ ਹਨ। ਉਦਾਹਰਨ ਲਈ, 6.10 ਕਰਨਲ ਉੱਤੇ CentOS 6.10 ਅਤੇ RHEL 2.6.32 ਵਿੱਚ ਨਵੇਂ ਕਰਨਲ ਵਿੱਚ ਲਾਗੂ ਕੀਤੀਆਂ ਗਈਆਂ ਬਹੁਤੀਆਂ ਨਾਜ਼ੁਕ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੀ ਘਾਟ ਹੈ ਜਿਵੇਂ ਕਿ SMAP, ਸਖ਼ਤ RWX ਅਨੁਮਤੀਆਂ, ਐਡਰੈੱਸ ਰੈਂਡਮਾਈਜ਼ੇਸ਼ਨ ਜਾਂ copy2usr ਸੁਰੱਖਿਆ। ਇਹ ਨੋਟ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਸਾਰਣੀ ਵਿੱਚ ਬਹੁਤ ਸਾਰੀਆਂ ਸੰਰਚਨਾ ਚੋਣਾਂ ਕਰਨਲ ਦੇ ਪੁਰਾਣੇ ਸੰਸਕਰਣਾਂ ਵਿੱਚ ਉਪਲਬਧ ਨਹੀਂ ਹਨ ਅਤੇ ਅਸਲ ਵਿੱਚ ਲਾਗੂ ਨਹੀਂ ਹਨ - ਇਹ ਅਜੇ ਵੀ ਸਾਰਣੀ ਵਿੱਚ ਸਹੀ ਸੁਰੱਖਿਆ ਦੀ ਘਾਟ ਵਜੋਂ ਦਰਸਾਈ ਗਈ ਹੈ। ਇਸੇ ਤਰ੍ਹਾਂ, ਜੇਕਰ ਇੱਕ ਸੰਰਚਨਾ ਵਿਕਲਪ ਦਿੱਤੇ ਗਏ ਸੰਸਕਰਣ ਵਿੱਚ ਮੌਜੂਦ ਨਹੀਂ ਹੈ, ਅਤੇ ਸੁਰੱਖਿਆ ਲਈ ਉਸ ਵਿਕਲਪ ਨੂੰ ਅਯੋਗ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਇੱਕ ਉਚਿਤ ਸੰਰਚਨਾ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ।

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

ਟੇਬਲ 2 ਵਿੱਚ ਐਂਟਰੀਆਂ ਨੂੰ ਹੋਰ ਵੇਖਦੇ ਹੋਏ, ਅਸੀਂ ਦੇਖਦੇ ਹਾਂ ਕਿ ਆਧੁਨਿਕ ਕਰਨਲ ਕਮਜ਼ੋਰੀਆਂ ਦੇ ਸ਼ੋਸ਼ਣ ਤੋਂ ਸੁਰੱਖਿਆ ਲਈ ਕਈ ਵਿਕਲਪ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ ਜਿਵੇਂ ਕਿ ਜਾਣਕਾਰੀ ਲੀਕੇਜ ਅਤੇ ਸਟੈਕ/ਹੀਪ ਓਵਰਫਲੋ। ਹਾਲਾਂਕਿ, ਅਸੀਂ ਦੇਖਿਆ ਹੈ ਕਿ ਸਭ ਤੋਂ ਤਾਜ਼ਾ ਪ੍ਰਸਿੱਧ ਡਿਸਟਰੀਬਿਊਸ਼ਨਾਂ ਨੇ ਅਜੇ ਤੱਕ ਵਧੇਰੇ ਗੁੰਝਲਦਾਰ ਸੁਰੱਖਿਆ ਨੂੰ ਲਾਗੂ ਨਹੀਂ ਕੀਤਾ ਹੈ (ਉਦਾਹਰਨ ਲਈ, ਪੈਚਾਂ ਦੇ ਨਾਲ gr ਸੁਰੱਖਿਆ) ਜਾਂ ਕੋਡ ਦੀ ਮੁੜ ਵਰਤੋਂ ਦੇ ਹਮਲਿਆਂ ਦੇ ਵਿਰੁੱਧ ਆਧੁਨਿਕ ਸੁਰੱਖਿਆ (ਉਦਾ. ਕੋਡ ਲਈ R^X ਵਰਗੀਆਂ ਸਕੀਮਾਂ ਨਾਲ ਰੈਂਡਮਾਈਜ਼ੇਸ਼ਨ ਦਾ ਸੁਮੇਲ). ਮਾਮਲੇ ਨੂੰ ਹੋਰ ਬਦਤਰ ਬਣਾਉਣ ਲਈ, ਇੱਥੋਂ ਤੱਕ ਕਿ ਇਹ ਵਧੇਰੇ ਉੱਨਤ ਸੁਰੱਖਿਆ ਹਮਲਿਆਂ ਦੀ ਪੂਰੀ ਸ਼੍ਰੇਣੀ ਤੋਂ ਬਚਾਅ ਨਹੀਂ ਕਰਦੇ ਹਨ। ਇਸ ਲਈ, ਸਿਸਟਮ ਪ੍ਰਸ਼ਾਸਕਾਂ ਲਈ ਸਮਾਰਟ ਕੌਂਫਿਗਰੇਸ਼ਨਾਂ ਨੂੰ ਹੱਲਾਂ ਦੇ ਨਾਲ ਪੂਰਕ ਕਰਨਾ ਮਹੱਤਵਪੂਰਨ ਹੈ ਜੋ ਰਨਟਾਈਮ ਸ਼ੋਸ਼ਣ ਖੋਜ ਅਤੇ ਰੋਕਥਾਮ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰਦੇ ਹਨ।

ਐਪਲੀਕੇਸ਼ਨ ਵਿਸ਼ਲੇਸ਼ਣ

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

ਵੰਡ

ਕੁੱਲ ਮਿਲਾ ਕੇ, ਅਸੀਂ ਸਾਰੇ ਡਿਸਟਰੀਬਿਊਸ਼ਨਾਂ ਲਈ 361 ਪੈਕੇਜ ਡਾਊਨਲੋਡ ਕੀਤੇ ਹਨ, ਸਿਰਫ਼ ਡਿਫਾਲਟ ਮਿਰਰਾਂ ਤੋਂ ਪੈਕੇਜਾਂ ਨੂੰ ਐਕਸਟਰੈਕਟ ਕਰਦੇ ਹੋਏ। ਅਸੀਂ ELF ਐਗਜ਼ੀਕਿਊਟੇਬਲ ਤੋਂ ਬਿਨਾਂ ਪੈਕੇਜਾਂ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕੀਤਾ, ਜਿਵੇਂ ਕਿ ਸਰੋਤ, ਫੌਂਟ, ਆਦਿ। ਫਿਲਟਰ ਕਰਨ ਤੋਂ ਬਾਅਦ, 556 ਪੈਕੇਜ ਰਹਿ ਗਏ, ਜਿਸ ਵਿੱਚ ਕੁੱਲ 129 ਬਾਈਨਰੀਆਂ ਹਨ। ਡਿਸਟਰੀਬਿਊਸ਼ਨਾਂ ਵਿੱਚ ਪੈਕੇਜਾਂ ਅਤੇ ਫਾਈਲਾਂ ਦੀ ਵੰਡ ਨੂੰ ਚਿੱਤਰ ਵਿੱਚ ਦਿਖਾਇਆ ਗਿਆ ਹੈ। 569.

ਅੰਜੀਰ. 3

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

ਅੰਜੀਰ. 4

ਲਗਭਗ ਸਾਰੀਆਂ ਵੰਡਾਂ ਵਿੱਚ, 60% ਪੈਕੇਜਾਂ ਵਿੱਚ ਘੱਟੋ-ਘੱਟ 10 ਨਿਰਭਰਤਾਵਾਂ ਹੁੰਦੀਆਂ ਹਨ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਕੁਝ ਪੈਕੇਜਾਂ ਵਿੱਚ ਕਾਫ਼ੀ ਜ਼ਿਆਦਾ ਨਿਰਭਰਤਾ (100 ਤੋਂ ਵੱਧ) ਹੁੰਦੀ ਹੈ। ਉਲਟਾ ਪੈਕੇਜ ਨਿਰਭਰਤਾਵਾਂ 'ਤੇ ਵੀ ਇਹੀ ਲਾਗੂ ਹੁੰਦਾ ਹੈ: ਜਿਵੇਂ ਕਿ ਉਮੀਦ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਵੰਡ ਵਿੱਚ ਕਈ ਹੋਰ ਪੈਕੇਜਾਂ ਦੁਆਰਾ ਕੁਝ ਪੈਕੇਜ ਵਰਤੇ ਜਾਂਦੇ ਹਨ, ਇਸਲਈ ਚੁਣੇ ਹੋਏ ਕੁਝ ਪੈਕੇਜਾਂ ਵਿੱਚ ਕਮਜ਼ੋਰੀਆਂ ਉੱਚ ਜੋਖਮ ਹੁੰਦੀਆਂ ਹਨ। ਇੱਕ ਉਦਾਹਰਨ ਦੇ ਤੌਰ 'ਤੇ, ਹੇਠਾਂ ਦਿੱਤੀ ਸਾਰਣੀ SLES, Centos 20, Debian 7 ਅਤੇ Ubuntu 9 (ਹਰੇਕ ਸੈੱਲ ਪੈਕੇਜ ਅਤੇ ਰਿਵਰਸ ਨਿਰਭਰਤਾਵਾਂ ਦੀ ਸੰਖਿਆ ਨੂੰ ਦਰਸਾਉਂਦੀ ਹੈ) ਵਿੱਚ ਵੱਧ ਤੋਂ ਵੱਧ ਰਿਵਰਸ ਨਿਰਭਰਤਾਵਾਂ ਵਾਲੇ 18.04 ਪੈਕੇਜਾਂ ਨੂੰ ਸੂਚੀਬੱਧ ਕਰਦੀ ਹੈ।

ਟੇਬਲ 3

ਦਿਲਚਸਪ ਤੱਥ. ਹਾਲਾਂਕਿ ਵਿਸ਼ਲੇਸ਼ਣ ਕੀਤੇ ਗਏ ਸਾਰੇ OS x86_64 ਆਰਕੀਟੈਕਚਰ ਲਈ ਬਣਾਏ ਗਏ ਹਨ, ਅਤੇ ਜ਼ਿਆਦਾਤਰ ਪੈਕੇਜਾਂ ਵਿੱਚ ਆਰਕੀਟੈਕਚਰ ਨੂੰ x86_64 ਅਤੇ x86 ਵਜੋਂ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤਾ ਗਿਆ ਹੈ, ਪੈਕੇਜਾਂ ਵਿੱਚ ਅਕਸਰ ਹੋਰ ਆਰਕੀਟੈਕਚਰ ਲਈ ਬਾਈਨਰੀਆਂ ਹੁੰਦੀਆਂ ਹਨ, ਜਿਵੇਂ ਕਿ ਚਿੱਤਰ 5 ਵਿੱਚ ਦਿਖਾਇਆ ਗਿਆ ਹੈ। XNUMX.

ਅੰਜੀਰ. 5

ਅਗਲੇ ਭਾਗ ਵਿੱਚ, ਅਸੀਂ ਵਿਸ਼ਲੇਸ਼ਣ ਕੀਤੀਆਂ ਬਾਈਨਰੀਆਂ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਬਾਰੇ ਵਿਚਾਰ ਕਰਾਂਗੇ।

ਬਾਈਨਰੀ ਫਾਈਲ ਸੁਰੱਖਿਆ ਅੰਕੜੇ

ਘੱਟੋ-ਘੱਟ, ਤੁਹਾਨੂੰ ਆਪਣੇ ਮੌਜੂਦਾ ਬਾਈਨਰੀਆਂ ਲਈ ਸੁਰੱਖਿਆ ਵਿਕਲਪਾਂ ਦੇ ਇੱਕ ਮੂਲ ਸੈੱਟ ਦੀ ਪੜਚੋਲ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਕਈ ਲੀਨਕਸ ਡਿਸਟਰੀਬਿਊਸ਼ਨ ਸਕ੍ਰਿਪਟਾਂ ਦੇ ਨਾਲ ਆਉਂਦੇ ਹਨ ਜੋ ਅਜਿਹੀਆਂ ਜਾਂਚਾਂ ਕਰਦੇ ਹਨ। ਉਦਾਹਰਨ ਲਈ, ਡੇਬੀਅਨ/ਉਬੰਟੂ ਕੋਲ ਅਜਿਹੀ ਸਕ੍ਰਿਪਟ ਹੈ। ਇੱਥੇ ਉਸਦੇ ਕੰਮ ਦੀ ਇੱਕ ਉਦਾਹਰਣ ਹੈ:

$ hardening-check $(which docker)
/usr/bin/docker:
 Position Independent Executable: yes
 Stack protected: yes
 Fortify Source functions: no, only unprotected functions found!
 Read-only relocations: yes
 Immediate binding: yes

ਸਕ੍ਰਿਪਟ ਪੰਜ ਦੀ ਜਾਂਚ ਕਰਦੀ ਹੈ ਸੁਰੱਖਿਆ ਫੰਕਸ਼ਨ:

• ਪੋਜ਼ੀਸ਼ਨ ਇੰਡੀਪੈਂਡੈਂਟ ਐਗਜ਼ੀਕਿਊਟੇਬਲ (PIE): ਇਹ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਕੀ ਇੱਕ ਪ੍ਰੋਗਰਾਮ ਦੇ ਟੈਕਸਟ ਸੈਕਸ਼ਨ ਨੂੰ ਰਲਵੇਂਕਰਨ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਮੈਮੋਰੀ ਵਿੱਚ ਮੂਵ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਜੇਕਰ ASLR ਕਰਨਲ ਵਿੱਚ ਸਮਰੱਥ ਹੈ।
• ਸਟੈਕ ਪ੍ਰੋਟੈਕਟਡ: ਕੀ ਸਟੈਕ ਕੈਨਰੀ ਸਟੈਕ ਟਕਰਾਅ ਦੇ ਹਮਲਿਆਂ ਤੋਂ ਸੁਰੱਖਿਆ ਲਈ ਸਮਰੱਥ ਹਨ।
• ਫੋਰਟੀਫਾਈ ਸੋਰਸ: ਕੀ ਅਸੁਰੱਖਿਅਤ ਫੰਕਸ਼ਨ (ਉਦਾਹਰਨ ਲਈ, strcpy) ਨੂੰ ਉਹਨਾਂ ਦੇ ਵਧੇਰੇ ਸੁਰੱਖਿਅਤ ਹਮਰੁਤਬਾ ਨਾਲ ਬਦਲਿਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਰਨਟਾਈਮ 'ਤੇ ਚੈੱਕ ਕੀਤੀਆਂ ਕਾਲਾਂ ਨੂੰ ਉਹਨਾਂ ਦੇ ਅਣਚੈਕ ਕੀਤੇ ਹਮਰੁਤਬਾ (ਉਦਾਹਰਨ ਲਈ, __memcpy_chk ਦੀ ਬਜਾਏ memcpy) ਨਾਲ ਬਦਲਿਆ ਜਾਂਦਾ ਹੈ।
• ਰੀਡ-ਓਨਲੀ ਰੀਲੋਕੇਸ਼ਨ (RELRO): ਕੀ ਰੀਲੋਕੇਸ਼ਨ ਟੇਬਲ ਐਂਟਰੀਆਂ ਨੂੰ ਸਿਰਫ਼-ਪੜ੍ਹਨ ਲਈ ਚਿੰਨ੍ਹਿਤ ਕੀਤਾ ਗਿਆ ਹੈ ਜੇਕਰ ਉਹਨਾਂ ਨੂੰ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਚਾਲੂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
• ਤੁਰੰਤ ਬਾਈਡਿੰਗ: ਕੀ ਰਨਟਾਈਮ ਲਿੰਕਰ ਪ੍ਰੋਗਰਾਮ ਦੇ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਸਾਰੀਆਂ ਚਾਲਾਂ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ (ਇਹ ਪੂਰੀ RELRO ਦੇ ਬਰਾਬਰ ਹੈ)।

ਕੀ ਉਪਰੋਕਤ ਵਿਧੀਆਂ ਕਾਫ਼ੀ ਹਨ? ਬਦਕਿਸਮਤੀ ਨਾਲ ਨਹੀਂ. ਉਪਰੋਕਤ ਸਾਰੇ ਬਚਾਅ ਪੱਖਾਂ ਨੂੰ ਬਾਈਪਾਸ ਕਰਨ ਦੇ ਜਾਣੇ-ਪਛਾਣੇ ਤਰੀਕੇ ਹਨ, ਪਰ ਬਚਾਅ ਜਿੰਨਾ ਸਖ਼ਤ ਹੋਵੇਗਾ, ਹਮਲਾਵਰ ਲਈ ਬਾਰ ਓਨੀ ਹੀ ਉੱਚੀ ਹੋਵੇਗੀ। ਉਦਾਹਰਣ ਲਈ, RELRO ਬਾਈਪਾਸ ਢੰਗ ਲਾਗੂ ਕਰਨਾ ਵਧੇਰੇ ਮੁਸ਼ਕਲ ਹੈ ਜੇਕਰ PIE ਅਤੇ ਤੁਰੰਤ ਬਾਈਡਿੰਗ ਪ੍ਰਭਾਵੀ ਹੈ। ਇਸੇ ਤਰ੍ਹਾਂ, ਪੂਰੇ ASLR ਨੂੰ ਕਾਰਜਸ਼ੀਲ ਸ਼ੋਸ਼ਣ ਬਣਾਉਣ ਲਈ ਵਾਧੂ ਕੰਮ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਹਾਲਾਂਕਿ, ਸੂਝਵਾਨ ਹਮਲਾਵਰ ਪਹਿਲਾਂ ਹੀ ਅਜਿਹੀਆਂ ਸੁਰੱਖਿਆਵਾਂ ਨੂੰ ਪੂਰਾ ਕਰਨ ਲਈ ਤਿਆਰ ਹਨ: ਉਨ੍ਹਾਂ ਦੀ ਗੈਰਹਾਜ਼ਰੀ ਜ਼ਰੂਰੀ ਤੌਰ 'ਤੇ ਹੈਕ ਨੂੰ ਤੇਜ਼ ਕਰੇਗੀ। ਇਸ ਲਈ ਇਹ ਜ਼ਰੂਰੀ ਹੈ ਕਿ ਇਹ ਉਪਾਅ ਜ਼ਰੂਰੀ ਸਮਝੇ ਜਾਣ ਘੱਟੋ ਘੱਟ.

ਅਸੀਂ ਅਧਿਐਨ ਕਰਨਾ ਚਾਹੁੰਦੇ ਸੀ ਕਿ ਪ੍ਰਸ਼ਨ ਵਿੱਚ ਵੰਡੀਆਂ ਵਿੱਚ ਕਿੰਨੀਆਂ ਬਾਈਨਰੀ ਫਾਈਲਾਂ ਇਹਨਾਂ ਅਤੇ ਤਿੰਨ ਹੋਰ ਤਰੀਕਿਆਂ ਦੁਆਰਾ ਸੁਰੱਖਿਅਤ ਹਨ:

• ਚੱਲਣਯੋਗ ਬਿੱਟ (NX) ਕਿਸੇ ਵੀ ਖੇਤਰ ਵਿੱਚ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਨੂੰ ਰੋਕਦਾ ਹੈ ਜੋ ਐਗਜ਼ੀਕਿਊਟੇਬਲ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ, ਜਿਵੇਂ ਕਿ ਸਟੈਕ ਹੀਪ, ਆਦਿ।
• RPATH/RUNPATH ਮੇਲ ਖਾਂਦੀਆਂ ਲਾਇਬ੍ਰੇਰੀਆਂ ਨੂੰ ਲੱਭਣ ਲਈ ਡਾਇਨਾਮਿਕ ਲੋਡਰ ਦੁਆਰਾ ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਮਾਰਗ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ। ਪਹਿਲਾ ਹੈ ਲਾਜ਼ਮੀ ਕਿਸੇ ਵੀ ਆਧੁਨਿਕ ਸਿਸਟਮ ਲਈ: ਇਸਦੀ ਗੈਰਹਾਜ਼ਰੀ ਹਮਲਾਵਰਾਂ ਨੂੰ ਮਨਮਾਨੇ ਢੰਗ ਨਾਲ ਪੇਲੋਡ ਨੂੰ ਮੈਮੋਰੀ ਵਿੱਚ ਲਿਖਣ ਅਤੇ ਇਸਨੂੰ ਜਿਵੇਂ ਹੈ, ਉਸੇ ਤਰ੍ਹਾਂ ਚਲਾਉਣ ਦੀ ਆਗਿਆ ਦਿੰਦੀ ਹੈ। ਦੂਜੇ ਲਈ, ਗਲਤ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਮਾਰਗ ਸੰਰਚਨਾ ਅਵਿਸ਼ਵਾਸਯੋਗ ਕੋਡ ਨੂੰ ਪੇਸ਼ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦੀ ਹੈ ਜਿਸ ਨਾਲ ਕਈ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਹੋ ਸਕਦੀਆਂ ਹਨ (ਜਿਵੇਂ ਕਿ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਵਾਧਾਅਤੇ ਹੋਰ ਸਮੱਸਿਆਵਾਂ).
• ਸਟੈਕ ਟੱਕਰ ਸੁਰੱਖਿਆ ਉਹਨਾਂ ਹਮਲਿਆਂ ਤੋਂ ਸੁਰੱਖਿਆ ਪ੍ਰਦਾਨ ਕਰਦੀ ਹੈ ਜੋ ਸਟੈਕ ਨੂੰ ਮੈਮੋਰੀ ਦੇ ਦੂਜੇ ਖੇਤਰਾਂ (ਜਿਵੇਂ ਕਿ ਢੇਰ) ਨੂੰ ਓਵਰਲੈਪ ਕਰਨ ਦਾ ਕਾਰਨ ਬਣਦੇ ਹਨ। ਹਾਲ ਹੀ ਦੇ ਕਾਰਨਾਮੇ ਦੁਰਵਿਵਹਾਰ ਨੂੰ ਦਿੱਤਾ ਸਿਸਟਮਡ ਹੀਪ ਟੱਕਰ ਕਮਜ਼ੋਰੀਆਂ, ਅਸੀਂ ਮਹਿਸੂਸ ਕੀਤਾ ਕਿ ਸਾਡੇ ਡੇਟਾਸੈਟ ਵਿੱਚ ਇਸ ਵਿਧੀ ਨੂੰ ਸ਼ਾਮਲ ਕਰਨਾ ਉਚਿਤ ਸੀ।

ਇਸ ਲਈ, ਬਿਨਾਂ ਕਿਸੇ ਰੁਕਾਵਟ ਦੇ, ਆਓ ਨੰਬਰਾਂ 'ਤੇ ਉਤਰੀਏ। ਟੇਬਲ 4 ਅਤੇ 5 ਵਿੱਚ ਕ੍ਰਮਵਾਰ ਵੱਖ-ਵੱਖ ਡਿਸਟਰੀਬਿਊਸ਼ਨਾਂ ਦੀਆਂ ਐਗਜ਼ੀਕਿਊਟੇਬਲ ਫਾਈਲਾਂ ਅਤੇ ਲਾਇਬ੍ਰੇਰੀਆਂ ਦੇ ਵਿਸ਼ਲੇਸ਼ਣ ਦਾ ਸਾਰ ਸ਼ਾਮਲ ਹੈ।

• ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਵੇਖ ਸਕਦੇ ਹੋ, ਬਹੁਤ ਘੱਟ ਅਪਵਾਦਾਂ ਦੇ ਨਾਲ, NX ਸੁਰੱਖਿਆ ਨੂੰ ਹਰ ਜਗ੍ਹਾ ਲਾਗੂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਖਾਸ ਤੌਰ 'ਤੇ, ਕੋਈ CentOS, RHEL ਅਤੇ OpenSUSE ਦੇ ਮੁਕਾਬਲੇ ਉਬੰਟੂ ਅਤੇ ਡੇਬੀਅਨ ਡਿਸਟਰੀਬਿਊਸ਼ਨਾਂ ਵਿੱਚ ਇਸਦੀ ਥੋੜੀ ਘੱਟ ਵਰਤੋਂ ਨੂੰ ਨੋਟ ਕਰ ਸਕਦਾ ਹੈ।
• ਸਟੈਕ ਕੈਨਰੀਆਂ ਬਹੁਤ ਸਾਰੀਆਂ ਥਾਵਾਂ 'ਤੇ ਗਾਇਬ ਹਨ, ਖਾਸ ਤੌਰ 'ਤੇ ਪੁਰਾਣੇ ਕਰਨਲ ਨਾਲ ਵੰਡਣ ਵਿੱਚ। Centos, RHEL, Debian ਅਤੇ Ubuntu ਦੇ ਨਵੀਨਤਮ ਵੰਡਾਂ ਵਿੱਚ ਕੁਝ ਪ੍ਰਗਤੀ ਦੇਖੀ ਜਾ ਰਹੀ ਹੈ।
• ਡੇਬੀਅਨ ਅਤੇ ਉਬੰਟੂ 18.04 ਦੇ ਅਪਵਾਦ ਦੇ ਨਾਲ, ਜ਼ਿਆਦਾਤਰ ਡਿਸਟਰੀਬਿਊਸ਼ਨਾਂ ਵਿੱਚ ਪੀਆਈਈ ਸਹਾਇਤਾ ਮਾੜੀ ਹੈ।
• ਸਟੈਕ ਟੱਕਰ ਸੁਰੱਖਿਆ OpenSUSE, Centos 7 ਅਤੇ RHEL 7 ਵਿੱਚ ਕਮਜ਼ੋਰ ਹੈ, ਅਤੇ ਹੋਰਾਂ ਵਿੱਚ ਅਸਲ ਵਿੱਚ ਗੈਰ-ਮੌਜੂਦ ਹੈ।
• ਆਧੁਨਿਕ ਕਰਨਲ ਵਾਲੀਆਂ ਸਾਰੀਆਂ ਵੰਡਾਂ ਵਿੱਚ RELRO ਲਈ ਕੁਝ ਸਮਰਥਨ ਹੈ, ਜਿਸ ਵਿੱਚ ਉਬੰਟੂ 18.04 ਸਭ ਤੋਂ ਅੱਗੇ ਹੈ ਅਤੇ ਡੇਬੀਅਨ ਦੂਜੇ ਨੰਬਰ 'ਤੇ ਹੈ।

ਜਿਵੇਂ ਕਿ ਪਹਿਲਾਂ ਹੀ ਦੱਸਿਆ ਗਿਆ ਹੈ, ਇਸ ਸਾਰਣੀ ਵਿੱਚ ਮੈਟ੍ਰਿਕਸ ਬਾਈਨਰੀ ਫਾਈਲ ਦੇ ਸਾਰੇ ਸੰਸਕਰਣਾਂ ਲਈ ਔਸਤ ਹਨ। ਜੇ ਤੁਸੀਂ ਸਿਰਫ਼ ਫਾਈਲਾਂ ਦੇ ਨਵੀਨਤਮ ਸੰਸਕਰਣਾਂ ਨੂੰ ਦੇਖਦੇ ਹੋ, ਤਾਂ ਨੰਬਰ ਵੱਖਰੇ ਹੋਣਗੇ (ਉਦਾਹਰਨ ਲਈ, ਵੇਖੋ PIE ਲਾਗੂ ਕਰਨ ਦੇ ਨਾਲ ਡੇਬੀਅਨ ਪ੍ਰਗਤੀ). ਇਸ ਤੋਂ ਇਲਾਵਾ, ਜ਼ਿਆਦਾਤਰ ਡਿਸਟ੍ਰੀਬਿਊਸ਼ਨ ਆਮ ਤੌਰ 'ਤੇ ਅੰਕੜਿਆਂ ਦੀ ਗਣਨਾ ਕਰਦੇ ਸਮੇਂ ਬਾਈਨਰੀ ਵਿੱਚ ਕੁਝ ਫੰਕਸ਼ਨਾਂ ਦੀ ਸੁਰੱਖਿਆ ਦੀ ਜਾਂਚ ਕਰਦੇ ਹਨ, ਪਰ ਸਾਡਾ ਵਿਸ਼ਲੇਸ਼ਣ ਫੰਕਸ਼ਨਾਂ ਦੀ ਸਹੀ ਪ੍ਰਤੀਸ਼ਤਤਾ ਦਿਖਾਉਂਦਾ ਹੈ ਜੋ ਸਖ਼ਤ ਹਨ। ਇਸ ਲਈ, ਜੇਕਰ 5 ਵਿੱਚੋਂ 50 ਫੰਕਸ਼ਨਾਂ ਨੂੰ ਇੱਕ ਬਾਈਨਰੀ ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਅਸੀਂ ਇਸਨੂੰ 0,1 ਦਾ ਸਕੋਰ ਦੇਵਾਂਗੇ, ਜੋ ਕਿ ਮਜ਼ਬੂਤ ​​ਕੀਤੇ ਜਾਣ ਵਾਲੇ ਫੰਕਸ਼ਨਾਂ ਦੇ 10% ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ।

ਸਾਰਣੀ 4. ਚਿੱਤਰ ਵਿੱਚ ਵਿਖਾਈਆਂ ਗਈਆਂ ਐਗਜ਼ੀਕਿਊਟੇਬਲ ਫਾਈਲਾਂ ਲਈ ਸੁਰੱਖਿਆ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ। 3 (ਐਗਜ਼ੀਕਿਊਟੇਬਲ ਫਾਈਲਾਂ ਦੀ ਕੁੱਲ ਸੰਖਿਆ ਦੇ ਪ੍ਰਤੀਸ਼ਤ ਵਜੋਂ ਸੰਬੰਧਿਤ ਫੰਕਸ਼ਨਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨਾ)

ਸਾਰਣੀ 5. ਚਿੱਤਰ ਵਿੱਚ ਦਿਖਾਈਆਂ ਗਈਆਂ ਲਾਇਬ੍ਰੇਰੀਆਂ ਲਈ ਸੁਰੱਖਿਆ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ। 3 (ਲਾਇਬ੍ਰੇਰੀਆਂ ਦੀ ਕੁੱਲ ਸੰਖਿਆ ਦੇ ਪ੍ਰਤੀਸ਼ਤ ਵਜੋਂ ਸੰਬੰਧਿਤ ਕਾਰਜਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨਾ)

ਤਾਂ ਕੀ ਤਰੱਕੀ ਹੁੰਦੀ ਹੈ? ਨਿਸ਼ਚਤ ਤੌਰ 'ਤੇ ਇਹ ਹੈ: ਇਹ ਵਿਅਕਤੀਗਤ ਵੰਡਾਂ ਦੇ ਅੰਕੜਿਆਂ ਤੋਂ ਦੇਖਿਆ ਜਾ ਸਕਦਾ ਹੈ (ਉਦਾਹਰਨ ਲਈ, ਡੇਬੀਅਨ), ਅਤੇ ਨਾਲ ਹੀ ਉਪਰੋਕਤ ਟੇਬਲ ਤੋਂ। ਚਿੱਤਰ ਵਿੱਚ ਇੱਕ ਉਦਾਹਰਣ ਵਜੋਂ. ਚਿੱਤਰ 6 Ubuntu LTS 5 (ਅਸੀਂ ਸਟੈਕ ਟੱਕਰ ਸੁਰੱਖਿਆ ਅੰਕੜਿਆਂ ਨੂੰ ਛੱਡ ਦਿੱਤਾ ਹੈ) ਦੇ ਤਿੰਨ ਲਗਾਤਾਰ ਵੰਡਾਂ ਵਿੱਚ ਸੁਰੱਖਿਆ ਵਿਧੀਆਂ ਨੂੰ ਲਾਗੂ ਕਰਨਾ ਦਿਖਾਉਂਦਾ ਹੈ। ਅਸੀਂ ਦੇਖਿਆ ਹੈ ਕਿ ਸੰਸਕਰਣ ਤੋਂ ਸੰਸਕਰਣ ਤੱਕ ਵੱਧ ਤੋਂ ਵੱਧ ਫਾਈਲਾਂ ਸਟੈਕ ਕੈਨਰੀਆਂ ਦਾ ਸਮਰਥਨ ਕਰਦੀਆਂ ਹਨ, ਅਤੇ ਵੱਧ ਤੋਂ ਵੱਧ ਬਾਈਨਰੀਆਂ ਪੂਰੀ RELRO ਸੁਰੱਖਿਆ ਨਾਲ ਭੇਜੀਆਂ ਜਾਂਦੀਆਂ ਹਨ।

ਅੰਜੀਰ. 6

ਬਦਕਿਸਮਤੀ ਨਾਲ, ਵੱਖ-ਵੱਖ ਡਿਸਟਰੀਬਿਊਸ਼ਨਾਂ ਵਿੱਚ ਕਈ ਐਗਜ਼ੀਕਿਊਟੇਬਲ ਫਾਈਲਾਂ ਵਿੱਚ ਅਜੇ ਵੀ ਉਪਰੋਕਤ ਸੁਰੱਖਿਆਵਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਨਹੀਂ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਉਬੰਟੂ 18.04 ਨੂੰ ਦੇਖਦੇ ਹੋਏ, ਤੁਸੀਂ ngetty ਬਾਈਨਰੀ (ਇੱਕ ਗੈਟੀ ਰਿਪਲੇਸਮੈਂਟ), ਅਤੇ ਨਾਲ ਹੀ mksh ਅਤੇ lksh ਸ਼ੈੱਲ, picolisp ਇੰਟਰਪ੍ਰੇਟਰ, nvidia-cuda-ਟੂਲਕਿੱਟ ਪੈਕੇਜ (GPU-ਐਕਸਲਰੇਟਿਡ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ ਇੱਕ ਪ੍ਰਸਿੱਧ ਪੈਕੇਜ) ਵੇਖੋਗੇ। ਜਿਵੇਂ ਕਿ ਮਸ਼ੀਨ ਲਰਨਿੰਗ ਫਰੇਮਵਰਕ), ਅਤੇ klibc -utils। ਇਸੇ ਤਰ੍ਹਾਂ, ਮੈਂਡੋਸ-ਕਲਾਇੰਟ ਬਾਈਨਰੀ (ਇੱਕ ਪ੍ਰਬੰਧਕੀ ਟੂਲ ਜੋ ਤੁਹਾਨੂੰ ਐਨਕ੍ਰਿਪਟਡ ਫਾਈਲ ਸਿਸਟਮਾਂ ਨਾਲ ਮਸ਼ੀਨਾਂ ਨੂੰ ਆਟੋਮੈਟਿਕਲੀ ਰੀਬੂਟ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ) ਅਤੇ ਨਾਲ ਹੀ rsh-redone-client (rsh ਅਤੇ rlogin ਦਾ ਮੁੜ ਲਾਗੂ) ਬਿਨਾਂ NX ਸੁਰੱਖਿਆ ਦੇ ਸ਼ਿਪ, ਹਾਲਾਂਕਿ ਉਹਨਾਂ ਕੋਲ SUID ਅਧਿਕਾਰ ਹਨ: (. ਨਾਲ ਹੀ, ਕਈ ਸੂਡ ਬਾਇਨਰੀਆਂ ਵਿੱਚ ਬੁਨਿਆਦੀ ਸੁਰੱਖਿਆ ਦੀ ਘਾਟ ਹੈ ਜਿਵੇਂ ਕਿ ਸਟੈਕ ਕੈਨਰੀਜ਼ (ਉਦਾਹਰਨ ਲਈ, Xorg ਪੈਕੇਜ ਤੋਂ Xorg.wrap ਬਾਈਨਰੀ)।

ਸੰਖੇਪ ਅਤੇ ਸਮਾਪਤੀ ਟਿੱਪਣੀ

ਇਸ ਲੇਖ ਵਿੱਚ, ਅਸੀਂ ਆਧੁਨਿਕ ਲੀਨਕਸ ਡਿਸਟਰੀਬਿਊਸ਼ਨਾਂ ਦੀਆਂ ਕਈ ਸੁਰੱਖਿਆ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਉਜਾਗਰ ਕੀਤਾ ਹੈ। ਵਿਸ਼ਲੇਸ਼ਣ ਨੇ ਦਿਖਾਇਆ ਕਿ ਨਵੀਨਤਮ ਉਬੰਟੂ ਐਲਟੀਐਸ ਡਿਸਟਰੀਬਿਊਸ਼ਨ (18.04) ਔਸਤਨ, ਮੁਕਾਬਲਤਨ ਨਵੇਂ ਕਰਨਲ, ਜਿਵੇਂ ਕਿ ਉਬੰਟੂ 14.04, 12.04 ਅਤੇ ਡੇਬੀਅਨ 9 ਦੇ ਨਾਲ ਡਿਸਟਰੀਬਿਊਸ਼ਨਾਂ ਵਿੱਚ ਸਭ ਤੋਂ ਮਜ਼ਬੂਤ ​​​​OS ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਪੱਧਰ ਸੁਰੱਖਿਆ ਨੂੰ ਲਾਗੂ ਕਰਦਾ ਹੈ। ਹਾਲਾਂਕਿ, ਜਾਂਚ ਕੀਤੀ ਵੰਡ CentOS, RHEL ਅਤੇ ਸਾਡੇ ਸੈੱਟ ਵਿੱਚ ਓਪਨਸੂਸੇ ਮੂਲ ਰੂਪ ਵਿੱਚ ਉਹ ਪੈਕੇਜਾਂ ਦਾ ਇੱਕ ਸੰਘਣਾ ਸੈੱਟ ਤਿਆਰ ਕਰਦੇ ਹਨ, ਅਤੇ ਨਵੀਨਤਮ ਸੰਸਕਰਣਾਂ (ਸੈਂਟੋਸ ਅਤੇ ਆਰਐਚਈਐਲ) ਵਿੱਚ ਉਹਨਾਂ ਕੋਲ ਡੇਬੀਅਨ-ਅਧਾਰਿਤ ਪ੍ਰਤੀਯੋਗੀਆਂ (ਡੇਬੀਅਨ ਅਤੇ ਉਬੰਟੂ) ਦੇ ਮੁਕਾਬਲੇ ਸਟੈਕ ਟੱਕਰ ਸੁਰੱਖਿਆ ਦੀ ਉੱਚ ਪ੍ਰਤੀਸ਼ਤਤਾ ਹੈ। CentOS ਅਤੇ RedHat ਸੰਸਕਰਣਾਂ ਦੀ ਤੁਲਨਾ ਕਰਦੇ ਹੋਏ, ਅਸੀਂ ਸੰਸਕਰਣ 6 ਤੋਂ 7 ਤੱਕ ਸਟੈਕ ਕੈਨਰੀ ਅਤੇ RELRO ਨੂੰ ਲਾਗੂ ਕਰਨ ਵਿੱਚ ਵੱਡੇ ਸੁਧਾਰ ਵੇਖਦੇ ਹਾਂ, ਪਰ ਔਸਤਨ CentOS ਵਿੱਚ RHEL ਨਾਲੋਂ ਵਧੇਰੇ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਲਾਗੂ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ। ਆਮ ਤੌਰ 'ਤੇ, ਸਾਰੀਆਂ ਵੰਡਾਂ ਨੂੰ PIE ਸੁਰੱਖਿਆ 'ਤੇ ਵਿਸ਼ੇਸ਼ ਧਿਆਨ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ, ਜੋ ਡੇਬੀਅਨ 9 ਅਤੇ ਉਬੰਟੂ 18.04 ਦੇ ਅਪਵਾਦ ਦੇ ਨਾਲ, ਸਾਡੇ ਡੇਟਾਸੈਟ ਵਿੱਚ 10% ਤੋਂ ਘੱਟ ਬਾਈਨਰੀਆਂ ਵਿੱਚ ਲਾਗੂ ਕੀਤਾ ਗਿਆ ਹੈ।

ਅੰਤ ਵਿੱਚ, ਇਹ ਨੋਟ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਹਾਲਾਂਕਿ ਅਸੀਂ ਖੋਜ ਹੱਥੀਂ ਕੀਤੀ ਹੈ, ਇੱਥੇ ਬਹੁਤ ਸਾਰੇ ਸੁਰੱਖਿਆ ਸਾਧਨ ਉਪਲਬਧ ਹਨ (ਉਦਾ. ਲੀਨਿਸ, ਟਾਈਗਰ, Hubble), ਜੋ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਦੇ ਹਨ ਅਤੇ ਅਸੁਰੱਖਿਅਤ ਸੰਰਚਨਾਵਾਂ ਤੋਂ ਬਚਣ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ। ਬਦਕਿਸਮਤੀ ਨਾਲ, ਵਾਜਬ ਸੰਰਚਨਾਵਾਂ ਵਿੱਚ ਵੀ ਮਜ਼ਬੂਤ ​​ਸੁਰੱਖਿਆ ਕਾਰਨਾਮੇ ਦੀ ਅਣਹੋਂਦ ਦੀ ਗਰੰਟੀ ਨਹੀਂ ਦਿੰਦੀ। ਇਸ ਲਈ ਅਸੀਂ ਪੱਕਾ ਵਿਸ਼ਵਾਸ ਕਰਦੇ ਹਾਂ ਕਿ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣਾ ਬਹੁਤ ਜ਼ਰੂਰੀ ਹੈ ਰੀਅਲ ਟਾਈਮ ਵਿੱਚ ਹਮਲਿਆਂ ਦੀ ਭਰੋਸੇਯੋਗ ਨਿਗਰਾਨੀ ਅਤੇ ਰੋਕਥਾਮ, ਸ਼ੋਸ਼ਣ ਦੇ ਪੈਟਰਨਾਂ 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਿਤ ਕਰਨਾ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਰੋਕਣਾ।

ਸਰੋਤ: www.habr.com